search for: libdtrac

Does dtrace have a problem catching the return from memset on Mac OSX? The script below catches the entry just fine but the return clause is never entered. Thanks, Joel --- pid$target::memset:entry /arg1 == 0/ { self->size = arg2; self->ts = timestamp; self->vts = vtimestamp; } pid$target::memset:return /self->size/ { @ts = sum(timestamp - self->ts); @vts =

...n Jun 18 10:18:54 CEST 2012 root@zozo.afpicl.lan:/usr/obj/usr/src/sys/CORE amd64 # svnversion 238067M # make NOCLEAN=yes NO_CLEAN=yes buildworld [...] ===> cddl/lib (obj,depend,all,install) ===> cddl/lib/drti (obj) ===> cddl/lib/libavl (obj) ===> cddl/lib/libctf (obj) ===> cddl/lib/libdtrace (obj) ===> cddl/lib/libnvpair (obj) ===> cddl/lib/libumem (obj) ===> cddl/lib/libuutil (obj) ===> cddl/lib/libzfs (obj) ===> cddl/lib/libzpool (obj) ===> cddl/lib/drti (depend) ===> cddl/lib/libavl (depend) ===> cddl/lib/libctf (depend) ===> cddl/lib/libdtrace (depend) =...

...lows 6311960 allow some DTrace options to be set dynamically 6311963 jstack() produces stacks packed with "StubRoutines" 6311975 allow boolean DTrace options to be unset 6315028 allow quantize()/lquantize() increments to be D expressions 6315033 add dtrace_addr2str()/dtrace_uaddr2str() to libdtrace API 6315034 add ucaller variable 6315035 enablings containing USDT probes are not dynamically reevaluated 6315037 cannot aggregate on the return value of some subroutines 6315039 including <sys/kstat.h> in a D script induces compile-time error 6315087 stack() not correctly printed for 32-bit...

Hi, Chris (cc) and I try to get the SGE master monitor work with Apple Leopard dtrace. Unfortunately we are stuck with the error msg below. Anyone having an idea what could be the cause? What I can rule out as cause is function inlining for the reasons explained below. Background information on SGE master monitor implementation is under http://wiki.gridengine.info/wiki/index.php/Dtrace

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

Hi, I''m posting a question hoping someone will know the answer off hand thereby reducing my search time. :-) With USDT probes, the tracepoint is only installed by libdtrace itself, never by the drti ioctl. So whenever I run a program with an USDT probe, no tracepoint is installed. Only after I run the dtrace command the tracepoint is actually installed on the victim process. My question is about how Solaris discovers the correct instruction pointer (PC) on the targe...

...g together parts of chime, the Web Stack Apache, Ruby and PHP providers, and stuff reused from the DTrace toolkit. It''s in it''s early days, but we''d obviously like to build on top of this. Since it uses chime, at the lowest levels it also uses the DTrace Java APIs and libdtrace. However, we''ve had one challenge for which we''ve not yet found a solution. All of the Web Stack components run as different users. For example, Apache runs as webservd and mysql runs as mysql. In Web Stack, we have some scripts which set up a user profile and permissions...

...leak dynamic variable state 6295662 plockstat needs more characters for stack addresses 6296903 invalid memory accesses clear other DTrace error bits Files: update: usr/src/cmd/dtrace/dtrace.c update: usr/src/cmd/intrstat/intrstat.c update: usr/src/cmd/plockstat/plockstat.c update: usr/src/lib/libdtrace/common/dt_link.c update: usr/src/lib/libdtrace/common/dt_map.c update: usr/src/lib/libdtrace/common/dt_open.c update: usr/src/lib/libdtrace/common/dt_options.c update: usr/src/uts/common/dtrace/dtrace.c update: usr/src/uts/common/dtrace/sdt_subr.c update: usr/src/uts/common/io/avintr.c upda...

Author: ahl Repository: /hg/zfs-crypto/gate Revision: b1ab97f77b0ad2a4fe2a43d9c5aac7259840bb90 Log message: 6370454 dtrace should support USDT probes in static functions Files: update: usr/src/lib/libdtrace/common/dt_dof.c update: usr/src/lib/libdtrace/common/dt_link.c update: usr/src/lib/libdtrace/common/dt_provider.c update: usr/src/lib/libdtrace/common/dt_provider.h

I''d like to prepend TRACE_ to the macro names generated by dtrace -h. For example, change POSTGRESQL_LWLOCK_ACQUIRE(arg0, arg1) to TRACE_POSTGRESQL_LWLOCK_ACQUIRE(arg0, arg1) and still keep postgresql as the provider name. The reason for doing this is to make it clear that the macros are used for (D)tracing. In this particular case, without TRACE_, it appears like the macro is used

What''s going on? # dtrace -s iotime_all.d 100 dtrace: failed to enable ''iotime_all.d'': DIF program content is invalid The errant script.... #pragma D option quiet BEGIN { stime = timestamp; io_count = 0; } io:::start /args[2]->fi_pathname != "<none>"/ { start[pid, args[2]->fi_pathname, args[0]->b_edev, args[0]->b_blkno,

[Perhaps someone could rename this list to dtrace-matt-problems-discuss?] If I run this script against my binary (which contains a USDT probe called ''concurrentq-latency''): ::: / probename == "concurrentq-latency" / { printf("[%s]:[%s]:[%s]\n", probeprov, probefunc, probename); } I get this output: dtrace: script ''testq.d'' matched 46056

I''m trying to install CiscoWorks 2.5 on Solaris 10 update 1, and after the install when I try to start the daemon, it errors: # /opt/CSCOpx/objects/dmgt/dmgtd.sol ERROR: open file dmgtd failedERROR >>>>>>>>>>>>> open msg catalog failed. NLSPATH incorrect or objects/share/nls/C/dmgtd.cat is missing. # echo $NLSPATH

...(100003faa, ffffffff7ffff5c8, ffffffff7eca1114, ffffffff7fffec79, 0, 100003fa9) libc.so.1`snprintf+0x88(ffffffff7ffff8f0, 0, 100003fa8, 0, ffffffff7ffff620, 100003000) 0x100001cd8(10068c060, fecb8d70, ffffffff7ffff8f0, 28, 1, 1d) 0x100001ff4(100805b08, 100805b28, 5, 100805b20, 100805af8, 100106990) libdtrace.so.1`dt_aggregate_walk_sorted+0xa4(10010b500, 100001de8, 0, ffffffff7f124f08, 1, 100806e70) main+0xad0(100001, 100106000, 100000, 100001000, 100107228, 100106) _start+0x17c(0, 0, 0, 0, 0, 0) the command was: plockstat -a -p <jvm_pid> Thanks, Stefan -- This message posted from opensolaris.o...

If I have the following definition: provider foo { probe bar(const char*); }; and creates the headerfile (snv 43) with dtrace -h I get: extern void __dtrace_foo___bar(char *); This is a "problem" for me (ok, I could add an explicit cast each time I fire the probe, or edit the generated headerfile by hand...), since it generates compilation errors when I call the probe in a C++

...forceload: drv/profile forceload: drv/lockstat forceload: drv/fbt forceload: drv/fasttrap forceload: drv/systrace forceload: drv/sdt forceload: drv/profile forceload: drv/lockstat forceload: drv/fbt forceload: drv/fasttrap forceload: drv/dtrace * ^^^^ Added by DTrace It''s because when libdtrace searches for providers, it searches the system module load paths and attempts to match module names with pseudo drivers to locate the providers, so it will match not only for the dtrace providers in, say /platform/sun4u/mykernel/..., but also for the "originals" in /kernel/... It...

Just to let people know what my big picture is, I''m trying to write a script that will let me run a program, and name a progeny of that program that I want to debug. My script should find the first occurrence of that progeny, and run it until it finishes initializing the runtime linker, but stop it before it runs any shared library startup routines. (Failing that, I''d be okay

I''d like to see if we can use DTrace to as the kernel implementation of the BSD systrace security policy system (http://www.systrace.org). I don''t really want to port systrace to Solaris because I think with DTrace we already have all the necessary in kernel hooks to do this. With systrace you express things like: "httpd can bind to port 80 but not any other port, it

On 22 August 2018 at 04:27, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > However, if you pass the -emit-relocs option to the linker, lld keeps all > relocations that have already been resolved in an output executable. By > analyzing a relocation table in a resulting executable, you could find all > locations where the ifunc PLT is called. Then, you can

...0515f90 %rdi = 0x0000000000000000 %r13 = 0x00000000006a2dc0 %r14 = 0x00000000ffdfead0 %r15 = 0x00000000006a3d10 %cs = 0x0053 %fs = 0x0000 %gs = 0x0000 %ds = 0x0000 %es = 0x0000 %ss = 0x004b %rip = 0xfffffd7fff30826a libdtrace.so.1`dt_ident_cook+0x32 %rbp = 0xfffffd7fffdfeb10 %rsp = 0xfffffd7fffdfeae0 %rflags = 0x00010202 id=0 vip=0 vif=0 ac=0 vm=0 rf=1 nt=0 iopl=0x0 status=<of,df,IF,tf,sf,zf,af,pf,cf> %gsbase = 0x0000000000000000 %fsbase = 0xfffffd7ffef60200 %trapno = 0xe %err = 0x4 -- This m...