similar to: what is differenct between syscall::write:entry fbt::write:entry

I wrote a simple c programme and do some dtrace test. the progromme shows below(write.c): /////////////////////////////// #include<stdio.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> char *value="hello,my name is wanjm\n"; void main() { int fd; fd=open("/export/home/wanjm/temp/read.txt",O_RDWR|O_CREAT); while(1) {

Hi people, When working with some usdt C++ probes we have come across a few issues. Controlling USDT Function name: Putting in usdt probes into C++ code gives you the mangled enclosing function name for the probes Function name. Working around this can be a pain. You need to wrap your usdt probes in extern C functions and call these. Could we have an option to control the Function name for

Hi all, I am trying to write a D script which would print ustack() for every program in the system receiving SIGSEGV. All the stacks printed in trap()/sigtoproc() context do not have meaningful symbols. The following solves the problem to some degree but I''d much rather have a self-contained D script. dtrace -w -n ''fbt:genunix:sigtoproc:entry/arg2 == 11/ {

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

Hi I have a Dtrace script ( attached ) which examines memory usage, using fbt:genunix:anon_resvmem:entry & return On my T2000 it totals the 65k pages being reserved by my application, printing out the total in bytes. Seems to work well, tested with a small app that malloced < 65 K, malloced 200M and mmapeed a 16M file and it appeared to get things correct. Could I just get a second pair

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

Is there a list anywhere of the DTrace FBT provider calls for each version of Solaris since the Nevada build that hosed the DTrace Toolkit. I have no issue with rewriting what I need, but I am hoping to stave off having to look at all the source code to find everything. I know there is a new provider under development, but I need to be able to program DTrace routines for all the updates in

Hi All: In Solaris Dtrace User Guide, page 218, it says, "Functions that do not create a stack frame on x86 systems cannot be instrumented by FBT." Then what are these functions? What characteristics do they have? Regards TJ

All, The attached script is causing the following error message ... bash-3.00# ./zmon_bug.d dtrace: error on enabled probe ID 2 (ID 4394: fbt:genunix:copen:entry): invalid address (0xfd91747f) in predicate at DIF offset 120 dtrace: error on enabled probe ID 2 (ID 4394: fbt:genunix:copen:entry): invalid address (0xfef81a3f) in predicate at DIF offset 120 Any ideas? thxs Joe --

Is there any work on keeping DTraceTools up to date with the latest snv builds. These scripts are pretty useful and help get a novice dtrace user like me doing useful work quickly. Specifically the tcp stack tools like tcptop and tcpsnoop don''t work with later OpenSolaris builds. Thanks, Gary -- This message posted from opensolaris.org

$B!zCK@-$O40A4L5NAEPO?$r$7$FBT$D$@$1$G$9!#(B $B>/$74i$bA*$s$@J}$,$$$$$+$b!)!)$=$l$O$*G$$;$7$^$9!#(B http://www.00-love5.com/serebu/s.html $B!V(BYAHOO!$B!W!V(BGoogle$B!W$N8!:w7k2L$O$=$N%5%$%H$N?M5$!"(B $B?.MjEY!J%f!<%6!<$K$h$kEjI<!K$G=g0L$,7hDj$7$^$9!#(B $BEv%5%$%H$O8!:w%+%F%4%j(B $B!TAG?M%[%9%H!U$K$F%H%C%W%Z!<%8$G>R2p$5$l$F$$$^$9!#(B

I have a funny issue whereby when a application exits the proc:::exit probe doesn''t seem to be firing. A customer has written a dtrace script that outputs some info whenever proc:::exit fires but on occasion (random, no pattern in behaviour) dtrace exits without outputting the data. They are running dtrace via ''dtrace -s exit_trace.d -p <pid>'' Can anyone think

Hi, In migrating from **VM to ZFS am I going to have an issue with Major/Minor numbers with NFS mounts? Take the following scenario. 1. NFS clients are connected to an active NFS server that has SAN shared storage between the active and standby nodes in a cluster. 2. The NFS clients are using the major/minor numbers on the active node in the cluster to communicate to the NFS active server. 3.

As of patch 32953 dtrace support is in bleadperl (5.11.0). The probes are based on Alan Burlinson''s original blog post on the subject: http://blogs.sun.com/alanbur/date/20050909 By guarding the probes with PERL_SUB_*_ENABLED the performance hit is unmeasurable. All the necessary bits already existed in the wild. I just assembled them and made the necessary changes to

Dear R Users, When I installed e1071 use R CMD INSTALL, I got configure: WARNING: g++ 2.96 cannot reliably be used with this package. configure: error: Please use a different C++ compiler. But how to let R CMD INSTALL use a different C++ compiler? and which C++ compiler is good? -Luke

Howdy, I am attempting to isolate the location of a memory leak in a 4GL program, and have hit a bit of a snag. When I LD_PRELOAD libumem and run the application server, "::findleaks -fdv" reports numerous leaks: CACHE LEAKED BUFCTL CALLER 0000000100b49068 15 0000000100ef2d50 fdcon+0x6c4 0000000100b50028 1 0000000100b72ac0 fdcon+0x6c4 0000000100b49068

I have a test program which has a call sequence of a(), b(), c(), d(). When I place a pid return probe on d(), I get a ustack that looks like this: a.out`d+0x19 a.out`b+0xd a.out`a+0xd a.out`main+0x3c a.out`_start+0x7a The c() method appears to be missing. I did some poking around and noticed that pid return probes

I am getting the following error: dtrace: failed to compile script /usr/local/bin/sun-dtrace-script: line 15: probe description fbt::new_cpu_mstate:entry does not match any probes The system is amd64, and running a 127112-11. Any ideas?

I have been doing some profiling using the profile provider. I have a command that runs more slowly on the T1000 than it does on prior systems and I am trying to find out why. Using the profile provider at 1000 hz, and aggregating on the ustack output, I find that the same function appears at the top of the stack on both platforms, but on each there are specific instruction locations within

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