similar to: Limiting dtrace depth

Hi Folks, I''m trying to use DTrace to understand some complex code using the user process probe. Things are basically not matching up. When I use a variable to track depth, sometimes it jumps. Similarly, the flow indent seems off. I read another post saying that this is caused by missing return statements in functions.

We''re running a Solaris 10 container, with an Oracle 9.2.0.4 database - every 5-10 min, an Oracle process shoots up (using 20% + CPU) and then goes down in CPU %, doing a [i]pollsys [/i](see it via dtruss). I tried using some of the trace scripts in the Dtracetoolkit to see what the process is doing, but without any luck - also tried with the following, but dtrace process goes up to 30%

Hello all, I saw this question about a year back in the archive[1], but with no final answer. I would like to trace shmget calls and also get the id of the shared memory segment. That script looked like[2], but we dont get the id since arg1 is the errno value. How do i access the shm id, i would need this to debug a customer problem but i don''t have time to learn it the hard

I have a number of systems running solaris10 and i see the package and binary for dtrace installed however whenever we try to run anything we get this error dtrace: failed to initialize dtrace: DTrace device not available on system the only system in which i dont have this error is the development server that has the full solaris 10 install while others are minimized, do i need additional

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

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

Hi, suppose I do: b <- matrix(1:9,3,3) bname <- "b" now dim(b) returns [1] 3 3 and dim(bname) returns NULL is there a function to pass bname to such that dim returns the dimensions of b? like dim(somefunc(bname)) returns [1] 3 3 does 'somefunc' exist? daver +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |David Richmond It

Hi i''m trying to write my first dtrace script apparently i bit off a bit more than i can chew, i want to track io over sockets, i found your socketsize.d that gave me how to track writes, but i''m at a loss how to track reads, frankly i don''t see how your write tracker works because it uses a probe in a function that only takes two arguments but you grab size of write

I created a plugin to add simple Annotations to VarDecls and FieldDecls, and write this modified AST out to a file. I notice that when I use clang to compile this file I get different code then when I use the source directly. In both cases I'm compiling with -O4. Can anyone explain this? Thanks define i32 @somefunc(i32 (i32)* %ptr) nounwind uwtable { entry: %ptr.addr = alloca i32 (i32)*,

I''m curious to know what files are being used from a NFS server perspective. I''m unable to trace the client because it is in the boot phase. Looking at the io provider, I believe it does not allow you to look at what files are being requested. That would lead me to the fbt provider. Does anyone know what fbt provides the file handle for NFS client request on the NFS

Is it possible to use DTrace to display the number of arguments and their types for userland or kernel functions that are not explicitly instrumented or documented by their authors? We''re talking about functions provided by Veritas VxVM/VxFS and the like, and for example, we might want to try tracing I/Os from App => VxFS => VxVM => ssd driver to see where I/Os get aggregated or

> I created a plugin to add simple Annotations to VarDecls and > FieldDecls, and write this modified AST out to a file. I notice that > when I use clang to compile this file I get different code then when I > use the source directly. In both cases I'm compiling with -O4. Can > anyone explain this? This is how clang implements annotations on local variables, that's all.

hi, I am trying to find out the avg cpu time spent in each of my user methods (exclusive of other methods invoked by a method). Hence the following snippet failed miserably: ----------------------- pid$target:a.out::entry { time[probefunc] = timestamp;} pid$target:a.out::return { @spent[probefunc] = avg(timestamp - time[probefunc]);} END { printa(@spent);}

Hi, I have migrated an LLVM front-end from LLVM 3.5 to 3.8 and now to 3.9 and ORC, and there is a concept which I could not transfer. Consider: extern "C" { void somefunc() {} } … auto llvmfunc = llvm::Function::Create(type, llvmFunction::PrivateLinkage, "bla", module)); executionengine.addGlobalMapping(llvmfunc, &somefunc); // now I have llvmfunc to work with and

I''m using a fbt probe where I get a system call id as an argument, how do I look up the name of it? At the moment I''m post-processing the output using /etc/name/to_sysnum but that doesn''t feel right :) cheers, /Martin -- This message posted from opensolaris.org

what is differenct between syscall::write:entry fbt::write:entry are the two probe fires at the same place. -- This message posted from opensolaris.org

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;

David Chisnall wrote: >On 2 Oct 2012, at 03:26, Magee, Josh wrote: > >> 1) An address of a local variable is taken in such a way as to expose the >> address of a stack location. >> - Example: the address of a local on the RHS of an assignment, the >> address of a local passed into function. > > It also sounds like it would be triggered for a

Hi Nils, all, I tried the ''FBT-trick'' suggested below by Nils and (of course :-) ) it works and gives me a pile of output. Good enough to show that indeed Linux application behavior is not totally opaque, good enough to for instance show that ''system call mapping'' is taking place. I wonder, is there any documentation available for lxsyscall module ? To learn