similar to: Enable anonymous tracing make Sunw2100z hang during boot

I''m using DTrace''s anonymous tracing feature to trace through device drivers at boot time. With Solaris 10 Update 6 B5, I was unable to trace fbt based calls from the sd attach point. The error messages from the console are: NOTICE: enabling probe 0 (fbt::sdattach:entry) NOTICE: enabling probe 1 (fbt:::) NOTICE: enabling probe 2 (fbt::sdattach:return) NOTICE: enabling probe

Hi, I am trying to trace some functions that are executed at detach time, and it seems that just having dtrace around to instrument the module is causing a short circuit, whereas modunload will return (device busy). I understand that this makes sense, but how can I get around this if I want to trace stuff at detach time? Thanks, --S

Hi Dean, I haven't looked very closely at XRay so far, but I'm wondering if making CTF (common trace format, e.g. see http://diamon.org/ctf/) the default format for XRay traces would be useful? It seems it'd be nice to be able to reuse some of the tools that already exist for CTF, such as a graphical viewer (http://tracecompass.org/) or a converter library

I have a script where I can freely reference struct nameidata*, struct vnode*, etc. on Snow Leopard. How does DTrace know about these data types? I understand things like #pragma D depends_on library darwin.d where darwin.d has typedefs. I can''t find definitions of nameidata and vnode in any D scripts, though. How does it work? Thanks, Joel --- firefox for android!

Hello everybody! How do people generate the Compact Type Format (CTF) section? Do you have a special parser or employ gcc debug information? Is there any open utility to do this job? Best regards, Yaroslav

everyone, Just out of curiosity, I did a dtrace -n ''syscall:::entry { @num[execname, probefunc] = count(); }'' and looked at the entries produced by ''rm''. I see everything that rm did, *except* the unlinkat - which is unfortunate because I want to trace which processes have deleted which files. So - does dtrace contain unlinkat as a probe for a system call?

Hi llvm-dev, Recently, we've committed the beginnings of the llvm-xray [0] tool which allows for conveniently working with both XRay-instrumented libraries as well as XRay trace/log files. In the course of the review for the conversion tool [1] which turns a binary/raw XRay log file into YAML for human consumption purposes, a question arose as to how we intend to allow users to develop tools

OK, I''ve been fritzing around with something I noticed last night, thinking that I understood what was going on, but now it''s getting confusing again. A system that has been running for a couple of months had a hole in the probe ID list near the end in the middle of the fbt probes. And then a couple of syscall probes were stuck in the hole. It looked like this: ... 40311

Hi all, I have questions about something I observed just now: 1) on AMD64, S10u1: # dtrace -n ''fbt::copystr:entry{printf ("%p\n", args[0]);}'' -c /bin/pwd dtrace: invalid probe specifier fbt::copystr:entry{printf ("%p\n", args[0]);}: in action list: index 0 is out of range for fbt::copystr:entry args[ ] but # dtrace -n ''fbt::copystr:entry{printf

This is a belated heads up to let you know that I have merged DTrace to the releng7 branch in the nick of time before the feature freeze for 7.1. Those astute mailing list readers will note that the commit message appears to have gone missing. Well, either the dog ate it or subversion decided that it was for certain eyes only (and not yours, or mine). I have added a note to src/UPDATING

[1] Predicates in one-liners I would like to list the probe modules in my executable and then dynamically create a dscript to trace execution of those modules alone (by excluding the 3rd party and system libraries). I tried the below script without success. The conditional given in the predicate is not taking effect. Why is this so ? $ dtrace -ln ''pid$target:::

If I use a simple dtrace script such as this: fbt::somefunc:entry{self->trace=1;} fbt::somefunc:return{self->trace=0;} fbt:::entry{} fbt:::return{printf("%lx", arg1);} then it will descend to whatever depth is necessary If I want to limit it to say 3 functions deep, how can I do that? The quick answer I want to use is to do "self->depth++" on each entry and then

Whilst trying out some D to get an insight into what is the most common reason for a given function to return, I have bumped into an error I don''t understand. The first take on what I was trying to do was: # dtrace -n ''fbt:ip:ip_input:return{@home[arg0] = count();}'' and all was well. The next step was: # dtrace -n

Hello the maunal states "When the if statement is not in a block the else, if present, must appear on the same line as statement1. Otherwise the new line at the end of statement1 yields a syntactically complete statement that is evaluated." well, what is wrong with this if structure? I am getting an error on the line where "else" is thanks if (exists("f")){ dt

Hello, I do not know if i am facing a bug or a mistake (and if it is a bug i do = not know in which category I can put it on the bug tracker), so I post=20 my message here. I am trying to use the Morris function from the sensitivity package (but = that is not the problem). I created a (big) instruction that should=20 generate a morris object in which there is a data.frame i am interested=20

I want to go a lot deeper with my tracing of MySQL and to do so I want to look into MySQL Thread Descriptors (class THD). Inside is a great bulk of information utilized by a great many of the core functions within MySQL... I really want to get in there. So far I''ve had no luck though. It''s a C++ class, and I''m afraid that I''m approaching it like a C struct,

Hi all, OK, so this at first looked like a clear cut "Don''t do it, or at worst handle the results" issue my customer has come to me with, but the more we discuss it, the more it looks like we should have better ways of dealing with this issue. > We have user defined dtrace probe points in the application which use > as parameter 64 bit values: > > provider adv {

Hello, I''ve done this several times in the past but a co-worker is having problems getting anonymous tracing to work: dtrace -A -m su and we see updated /kernel/drv/dtrace.conf and fbt and dtrace forceloads added to /etc/system. Upon reboot the following errors occur (note that we are running snv_66): {0} ok boot disk Boot device: /pci at 0/pci at 0/pci at 2/scsi at 0/disk at 0 File

i am doing reads and writes to /dev/rdsk/c0t2d0s4 using dtrace to see how much time it took for ssdread and ssdwrite. It shows very small number 4 or 5. #pragma D option flowindent syscall::pread:entry { self->trace = 1; self->size = arg2; } syscall::pwrite:entry { self->trace = 1; self->size = arg2; } fbt:ssd:ssdread:entry /self->trace/ { self->start = timestamp;

My leaky memory says we moved entry-point into some form of debug record in the standard libraries, circa Solaris 8/9. Before that, my group maintained text files that listed all the entry-points and their parameters for libraries like libc.so, so that we could print out parameter values in apptrace(8). There''s a (small) chance the records are complete enough that dtrace could use the