broker5 at seznam.cz
2008-Aug-15 08:21 UTC
[dtrace-discuss] pid: excluding libraries, modules
Hi, I am facing another problem with pid provider. I''d like to trace my application but would like to not to trace libc and libnsl. I could use predicate like /probemod != "libc" && probemod != "libnsl"/ but having this dtrace keeps inserting probes into those libraries which causes considerable hardware resources consumption. So I would probably need to exclude it in probe description but patterns in probe descption doesn''t seem to allow me to do what I need. Does someone know any workaround or are there any plans for some improvement in this area? I know I am now the only one who is experiencing this problem: http://mail.opensolaris.org/pipermail/dtrace-discuss/2005-November/000729.html Thanks, j.
On Fri, Aug 15, 2008 at 3:21 AM, <broker5 at seznam.cz> wrote:> Hi, > > I am facing another problem with pid provider. I''d like to trace my application but would like to not to trace libc and libnsl. I could use predicate like /probemod != "libc" && probemod != "libnsl"/ but having this dtrace keeps inserting probes into those libraries which causes considerable hardware resources consumption. So I would probably need to exclude it in probe description but patterns in probe descption doesn''t seem to allow me to do what I need. > > Does someone know any workaround or are there any plans for some improvement in this area? I know I am now the only one who is experiencing this problem: http://mail.opensolaris.org/pipermail/dtrace-discuss/2005-November/000729.htmlGiven you can''t exclude these two libraries, another option is to explicitly list the other libraries that you''re interested in, or simply your application if that''s all that you care about. For example, instead of something like this, where you''re wildcarding probemod: pid$target:::entry { printf("Entered %s:%s\n", probemod, probefunc); } do something like this: pid$target:a.out::entry, pid$target:libfoo::entry, pid$target:libbar::entry { printf("Entered %s:%s\n", probemod, probefunc); } Chad
broker5 at seznam.cz
2008-Aug-15 13:26 UTC
[dtrace-discuss] pid: excluding libraries, modules
Yes, that would be an option but I would rather avoid difficult searching thru application''s library dependencies and specifying lot of libraries explicitly - for complex application this could be a really big amount. Thanks, J> ------------ P?vodn? zpr?va ------------ > Od: Chad Mynhier <cmynhier at gmail.com> > P?edm?t: Re: [dtrace-discuss] pid: excluding libraries, modules > Datum: 15.8.2008 14:04:25 > ---------------------------------------- > On Fri, Aug 15, 2008 at 3:21 AM, <broker5 at seznam.cz> wrote: > > Hi, > > > > I am facing another problem with pid provider. I''d like to trace my > application but would like to not to trace libc and libnsl. I could use > predicate like /probemod != "libc" && probemod != "libnsl"/ but having this > dtrace keeps inserting probes into those libraries which causes considerable > hardware resources consumption. So I would probably need to exclude it in probe > description but patterns in probe descption doesn''t seem to allow me to do what > I need. > > > > Does someone know any workaround or are there any plans for some improvement > in this area? I know I am now the only one who is experiencing this problem: > http://mail.opensolaris.org/pipermail/dtrace-discuss/2005-November/000729.html > > Given you can''t exclude these two libraries, another option is to > explicitly list the other libraries that you''re interested in, or > simply your application if that''s all that you care about. > > For example, instead of something like this, where you''re wildcarding probemod: > > pid$target:::entry > { > printf("Entered %s:%s\n", probemod, probefunc); > } > > do something like this: > > pid$target:a.out::entry, > pid$target:libfoo::entry, > pid$target:libbar::entry > { > printf("Entered %s:%s\n", probemod, probefunc); > } > > Chad > > >
2008/8/15 <broker5 at seznam.cz>:> >> ------------ P?vodn? zpr?va ------------ >> Od: Chad Mynhier <cmynhier at gmail.com> >> P?edm?t: Re: [dtrace-discuss] pid: excluding libraries, modules >> Datum: 15.8.2008 14:04:25 >> ---------------------------------------- >> On Fri, Aug 15, 2008 at 3:21 AM, <broker5 at seznam.cz> wrote: >> > Hi, >> > >> > I am facing another problem with pid provider. I''d like to trace my >> application but would like to not to trace libc and libnsl. I could use >> predicate like /probemod != "libc" && probemod != "libnsl"/ but having this >> dtrace keeps inserting probes into those libraries which causes considerable >> hardware resources consumption. So I would probably need to exclude it in probe >> description but patterns in probe descption doesn''t seem to allow me to do what >> I need. >> > >> > Does someone know any workaround or are there any plans for some improvement >> in this area? I know I am now the only one who is experiencing this problem: >> http://mail.opensolaris.org/pipermail/dtrace-discuss/2005-November/000729.html >> >> Given you can''t exclude these two libraries, another option is to >> explicitly list the other libraries that you''re interested in, or >> simply your application if that''s all that you care about. >> > > Yes, that would be an option but I would rather avoid difficult searching thru > application''s library dependencies and specifying lot of libraries explicitly - > for complex application this could be a really big amount.Hmm, so looking further at this, it seems that you should be able to do this. The code is using gmatch(3GEN) to match these patterns, so you should be able to use some convoluted shell globbing construct to do what you want. For example, this should exclude libc (although it would also exclude libcfoo, so it''s not a complete example): pid$target:lib[!c]*::entry Some debugging of the code, though, seems to show that we''re not matching what we should be. The function dt_pid_mod_filt() (http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libdtrace/common/dt_pid.c#368) is where the match should be occurring: 373 if (gmatch(obj, pp->dpp_mod)) 374 return (dt_pid_per_mod(pp, pmp, obj)); 375 376 (void) Plmid(pp->dpp_pr, pmp->pr_vaddr, &pp->dpp_lmid); 377 378 if ((pp->dpp_obj = strrchr(obj, ''/'')) == NULL) 379 pp->dpp_obj = obj; 380 else 381 pp->dpp_obj++; 382 383 dt_pid_objname(name, sizeof (name), pp->dpp_lmid, obj); 384 385 if (gmatch(name, pp->dpp_mod)) 386 return (dt_pid_per_mod(pp, pmp, obj)); Throwing some dt_dprintf() debugging in here shows that it''s actually trying to match a full pathname. For these probes: pid$target:[c]hadfoo::entry, pid$target:libn*::entry With dt_dprintf() statements like this just before the two gmatch(3GEN) calls: dt_dprintf("CHADFOO: Trying to match %s to %s\n", obj, pp->dpp_mod); dt_dprintf("CHADFOO: Trying to match %s to %s\n", name, pp->dpp_mod); I get this (pertinent) debugging output: libdtrace DEBUG: CHADFOO: Trying to match /tmp/chadfoo/chadfoo to [c]hadfoo libdtrace DEBUG: CHADFOO: Trying to match /tmp/chadfoo/chadfoo to [c]hadfoo libdtrace DEBUG: CHADFOO: Trying to match /lib/libnsl.so.1 to libn* libdtrace DEBUG: CHADFOO: Trying to match /lib/libnsl.so.1 to libn* I''ve not dug into the gmatch(3GEN) code yet, but I''d guess that it''s not matching because of the fully-qualified pathnames. Is this a bug that just needs a basename(3C) call? (I went looking for a bug that matches this, but I couldn''t find anything. I''ll open a bug if nobody else knows of an existing one.) Chad
2008/8/15 Chad Mynhier <cmynhier at gmail.com>:> I''ve not dug into the gmatch(3GEN) code yet, but I''d guess that it''s > not matching because of the fully-qualified pathnames. Is this a bug > that just needs a basename(3C) call? > > (I went looking for a bug that matches this, but I couldn''t find > anything. I''ll open a bug if nobody else knows of an existing one.)Well, just using basename(3C) will take care of the problem, even if it might not be the appropriate solution. I''ll file a bug for this. Chad
broker5 at seznam.cz
2008-Aug-16 10:34 UTC
[dtrace-discuss] pid: excluding libraries, modules
Hi Chad, Thanks for your help. Looking at the gmatch it seems it really only provides wildcards which already are described in dtrace wiki: "*" "?" "[!". Having only these I can''t see the way how to construct pattern which would match every string except "libc.so" and "libnsl.so". As this pattern matching lacks "logical or" the pattern that will exclude libc will match nsl and vice vesa resulting in match of both libs that should be excluded. I think with full-regexps this task would be easy to do. Thanks, J.> Hmm, so looking further at this, it seems that you should be able to > do this. The code is using gmatch(3GEN) to match these patterns, so > you should be able to use some convoluted shell globbing construct to > do what you want. For example, this should exclude libc (although it > would also exclude libcfoo, so it''s not a complete example):