similar to: DTrace Java API on Mac OS?

Author: tomee Repository: /hg/zfs-crypto/gate Revision: 367993089b181886f94c88ffa5759d0626e95ad7 Log message: PSARC 2006/054 DTrace JNI Binding 6384263 PSARC 2006/054 DTrace JNI Binding Files: create: usr/src/lib/libdtrace_jni/Makefile create: usr/src/lib/libdtrace_jni/Makefile.com create: usr/src/lib/libdtrace_jni/amd64/Makefile create: usr/src/lib/libdtrace_jni/common/dtj_attr.c create:

Tried to start up tcptop_snv on snv87 x86 and got <i>dtrace: failed to compile script /dev/fd/11: line 168: conn_tcp is not a member of struct conn_s</i> Line 288 has this line: <i>this->tcpp = (tcp_t *)this->connp->conn_tcp;</i> which, after looking at line 168 of <a

This is from a discussion on opensolaris-tools that is somewhat relevant for DTrace community. I wrote a simple D script (http://www.opensolaris.org/os/project/onnv/onnv_build/faster_builds/tools/dtrace/dirtrace.d) that collects data for each dmake process during the Solaris build. After that the data is post-processed by a Perl script

I have found that pid provider can not create memcpy:return probe for 64bit process on snv_110. For example, the pid is 10603, I will have following output for dtrace command: #dtrace -n pid10603:libc.so.1:memcpy:return dtrace: invalid probe specifier pid10603:libc.so.1:memcpy:return: probe description pid10603:libc.so.1:memcpy:return does not match any probes This just

Hello zfs-code, http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/vdev_cache.c 72 * All i/os smaller than zfs_vdev_cache_max will be turned into 73 * 1<<zfs_vdev_cache_bshift byte reads by the vdev_cache (aka software 74 * track buffer). At most zfs_vdev_cache_size bytes will be kept in each 75 * vdev''s vdev_cache. While it

Hi, If you have a custom kernel (and therefore have duplicates of everything in /kernel in your custom kernel) and have noticed that when you try to use anonymous tracing, dtrace adds multiple copies of the forceload directives to /etc/system, e.g.: * vvvv Added by DTrace * * The following forceload directives were added by dtrace(1M) to allow for * tracing during boot. If these

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''m working on a case where customer has a 3rd party streams driver/module, called uplink, which sits over Sun''s ce driver. This 3rd party module is used by the telco to perform telco grade NIC failover. The customer was given an IDR ce driver, to avoid a panic they were given. The IDR driver was successful in avoiding the panic, but now the customer is getting many

I am currently working on adding DTrace probes we have for Memcached 1.2.5 to the new binary protocol in 1.3 branch. The problem I am facing is that I should have had a new variable into the probe. When we added the probes, all memcached keys would be zeroterminated ascii strings, but in the binary protocol it may not be zero-terminated. So what do I do? According to

DTrace will be part of Mac OS X 10.5, according to this page: http://www.apple.com/macosx/leopard/xcode.html This message posted from opensolaris.org

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

All, With Jon Haslam''s exciting news about the DTrace doc wiki (if you haven''t seen it yet, make your way to http://wikis.sun.com/display/DTrace), and with some of the discussion with the Apple folks, I''m wondering if the time isn''t right for something of a DTrace summit, perhaps as an unconference. The idea here would not be a DTrace user group (though that

N_conreq:entry { self->x=1; calledaddr=(struct xaddrf *)arg3; callingaddr=(struct xaddrf *)arg4; trace(calledaddr->link_id); tracemem(calledaddr->DTE_MAC.lsap_add, 80); trace(callingaddr->link_id); tracemem(callingaddr->DTE_MAC.lsap_add, 80); } 0 -> N_conreq 255

After building and bfu''in the lastest ON build, any time I run a dtrace script I get a Seg Fault. Is there a dtrace for dtrace :) Doug root at prae> dtrace -n ''syscall::open*:entry { printf("%s %s",execname,copyinstr(arg0)); }'' Segmentation Fault (core dumped) root at prae> pstack core core ''core'' of 101364: dtrace -n

Hi, I have used dtrace in the past for diagnosing IO/filesystem related issues. So I am a bit familiar with dtrace scripts Now I want to diagnose performance problems in the java area. May be memory leak etc. The hotspot provider is not present. How can I get them? Does someone have any further advice? regards Hans -- This message posted from opensolaris.org

Hi all i want to view the stack trace of the real time java application using DTrace probes. i am using jrts provider for finding the information of real time threads. In this i have used the ustack(), jstack() and this gives the following type of information libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsymbolHandle_5pnGThread__v_+0x5e

We recently had a strange NFS performance anomaly between a V880 running snv_124 and two NetApp filers. To investigate, a DTrace NFSv4 (and eventually NFSv3) client provider would been extremely helpful. Unfortunately, all I could find were a request for code review of a v3 client provider and another request for help developing a v4 provider. Nothing seems to have come from those initiatives,

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

Support for thin reclamation depends on the SCSI "WRITE SAME" command; see this draft of a document from T10: http://www.t10.org/ftp/t10/document.05/05-270r0.pdf. I spent some time searching the source code for support for "WRITE SAME", but I wasn''t able to find much. I assume that if it was supported, it would be listed in this header file:

Hi, In Solairs Dtrace User Guide, page 193, it lists the arguments of ERROR probe. One of these arguments is arg3, it is explained as "The DIF offset into that action or -1 if not applicable". Then what does the abbr. DIF mean? Regards TJ