I have a very simple dtrace script ( shown below ).
This script works on simple programs just fine.
Now I want to use this script on a large C++ executable.
The executable is 8.5 meg in size on a x86 platform.
This executable has more than 10 threads in it.
I try to execute that the dtrace script and I get this error -
./adc.d 24930
dtrace: failed to compile script ./adc.d: line 7: failed to grab
process 24930
What is the error really trying to tell me ?
wr
#######################
#!/usr/sbin/dtrace -qs
BEGIN
{ flag = 1 ; }
END
{ flag = 0 ; }
pid$1:::entry
{
self->t[probefunc] = timestamp ;
}
pid$1:::return
/self->t[probefunc] && flag /
{ this->time = timestamp - self->t[probefunc] ;
@[probefunc] = avg(this->time) ;
self->t[probefunc] = 0 ;
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20100507/0965037a/attachment.html>
Hey William,
There are a variety of reasons why dtrace(1M) would be unable to grab the
process -- for example, if the process you identified doesn''t exist or
if you don''t have permissions to it. Try this:
truss -t open dtrace -s adc.d 24930
... you might see output like this:
...
open("/proc/24930/as", O_RDONLY|O_EXCL) Err#2 ENOENT
open("/proc/24930/as", O_RDONLY) Err#2 ENOENT
Adam
On May 7, 2010, at 11:43 AM, William Reich wrote:
> I have a very simple dtrace script ( shown below ).
> This script works on simple programs just fine.
>
> Now I want to use this script on a large C++ executable.
> The executable is 8.5 meg in size on a x86 platform.
> This executable has more than 10 threads in it.
>
> I try to execute that the dtrace script and I get this error ?
>
> ./adc.d 24930
> dtrace: failed to compile script ./adc.d: line 7: failed to grab process
24930
>
> What is the error really trying to tell me ?
>
> wr
> #######################
>
> #!/usr/sbin/dtrace -qs
> BEGIN
> { flag = 1 ; }
>
> END
> { flag = 0 ; }
> pid$1:::entry
> {
> self->t[probefunc] = timestamp ;
> }
>
> pid$1:::return
> /self->t[probefunc] && flag /
> { this->time = timestamp - self->t[probefunc] ;
> @[probefunc] = avg(this->time) ;
> self->t[probefunc] = 0 ;
> }
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
--
Adam Leventhal, Fishworks http://blogs.sun.com/ahl
Yes, I am trying to find my hotspots. However - NO dtrace script will work. Yes, the process does exist. ( I have to change the pid for each test performed. ) Yes, I am running dtrace as root, so I do have access to the process. wr -----Original Message----- From: Chad Mynhier [mailto:cmynhier at gmail.com] Sent: Friday, May 07, 2010 2:53 PM To: William Reich Subject: Re: [dtrace-discuss] dtrace / c++ / lots of threads On Fri, May 7, 2010 at 2:43 PM, William Reich <reich at ulticom.com> wrote:> > > > #!/usr/sbin/dtrace -qs > > BEGIN > > {?????? flag =? 1 ; } > > > > END > > {?????? flag = 0 ; } > > pid$1:::entry > > { > > self->t[probefunc] = timestamp ; > > } > > > > pid$1:::return > > /self->t[probefunc] && flag / > > {?????? this->time = timestamp - self->t[probefunc] ; > > ??????? @[probefunc] = avg(this->time) ; > > ??????? self->t[probefunc] = 0 ; > > }Unrelated question, but what is it that you''re trying to achieve with this script? Do you need to know how much time you''re spending in each and every function you call? Or are you just trying to get a feel for your hotspots? If it''s the latter, just use sampling, something like this: profile-997 / arg1 && pid == $1 / { @[ufunc(arg1)] = count(); } This is going to be far more lightweight, but it will still give you a feel for your hotspots. Enabling every single function entry and return probe is going to be very expensive. Chad ++++++++++++++++++++++++++++>I have a very simple dtrace script ( shown below ). >This script works on simple programs just fine. > >Now I want to use this script on a large C++ executable. >The executable is 8.5 meg in size on a x86 platform. >This executable has more than 10 threads in it. > >I try to execute that the dtrace script and I get this error - > >./adc.d 24930 >dtrace: failed to compile script ./adc.d: line 7: failed to grab process 24930 > >What is the error really trying to tell me ?
On 10.05.10 15:51, William Reich wrote:> Yes, I am trying to find my hotspots. > > However - NO dtrace script will work.how is it failing? like your initial script:>> Now I want to use this script on a large C++ executable. >> The executable is 8.5 meg in size on a x86 platform. >> This executable has more than 10 threads in it. >> >> I try to execute that the dtrace script and I get this error - >> >> ./adc.d 24930 >> dtrace: failed to compile script ./adc.d: line 7: failed to grab process 24930or differently? does this happen for any process you try to trace, or just for this one? Michael -- michael.schuster at oracle.com http://blogs.sun.com/recursion Recursion, n.: see ''Recursion''
only this process fails - ./adc.d 24930 dtrace: failed to compile script ./adc.d: line 7: failed to grab process 24930 This script works fine on any other process. -----Original Message----- From: Michael Schuster [mailto:michael.schuster at oracle.com] Sent: Monday, May 10, 2010 10:00 AM To: William Reich Cc: dtrace-discuss at opensolaris.org Subject: Re: [dtrace-discuss] dtrace / c++ / lots of threads On 10.05.10 15:51, William Reich wrote:> Yes, I am trying to find my hotspots. > > However - NO dtrace script will work.how is it failing? like your initial script:>> Now I want to use this script on a large C++ executable. >> The executable is 8.5 meg in size on a x86 platform. >> This executable has more than 10 threads in it. >> >> I try to execute that the dtrace script and I get this error - >> >> ./adc.d 24930 >> dtrace: failed to compile script ./adc.d: line 7: failed to grabprocess 24930 or differently? does this happen for any process you try to trace, or just for this one? Michael -- michael.schuster at oracle.com http://blogs.sun.com/recursion Recursion, n.: see ''Recursion''
On 10.05.10 21:01, William Reich wrote:> only this process fails - > > ./adc.d 24930 > dtrace: failed to compile script ./adc.d: line 7: failed to grab > process 24930 > > > This script works fine on any other process.so then the obvious question is: what''s different about that process/program? are you running it under a debugger or truss? Michael -- michael.schuster at oracle.com http://blogs.sun.com/recursion Recursion, n.: see ''Recursion''
as implied in the first email ( below ) , the only thing that I see as different between this particular process and any other is that a) the executable is 8.5 megs as it sits on the disk b) the executable has at least 10 threads in it. wr -----Original Message----- From: dtrace-discuss-bounces at opensolaris.org [mailto:dtrace-discuss-bounces at opensolaris.org] On Behalf Of Michael Schuster Sent: Tuesday, May 11, 2010 1:38 AM To: dtrace-discuss at opensolaris.org Subject: Re: [dtrace-discuss] dtrace / c++ / lots of threads On 10.05.10 21:01, William Reich wrote:> only this process fails - > > ./adc.d 24930 > dtrace: failed to compile script ./adc.d: line 7: failed to grab > process 24930 > > > This script works fine on any other process.so then the obvious question is: what''s different about that process/program? are you running it under a debugger or truss? Michael -- michael.schuster at oracle.com http://blogs.sun.com/recursion ++++++++++++++++++++++++++++++++++++ I have a very simple dtrace script ( shown below ). This script works on simple programs just fine. Now I want to use this script on a large C++ executable. The executable is 8.5 meg in size on a x86 platform. This executable has more than 10 threads in it. I try to execute that the dtrace script and I get this error - ./adc.d 24930 dtrace: failed to compile script ./adc.d: line 7: failed to grab process 24930 What is the error really trying to tell me ? wr ####################### #!/usr/sbin/dtrace -qs BEGIN { flag = 1 ; } END { flag = 0 ; } pid$1:::entry { self->t[probefunc] = timestamp ; } pid$1:::return /self->t[probefunc] && flag / { this->time = timestamp - self->t[probefunc] ; @[probefunc] = avg(this->time) ; self->t[probefunc] = 0 ; }
On 11.05.10 14:38, William Reich wrote:> as implied in the first email ( below ) , > the only thing that I see as different between this particular process > and any other > is that > a) the executable is 8.5 megs as it sits on the diskI don''t think this should be an issue ... but can you give some detail on how this executable is built?> b) the executable has at least 10 threads in it.the executable doesn''t have threads ;-) they''re a property of the running process, but I know what you mean: that shouldn''t be a problem, I just tried tracing firefox, which has more, and had no issue. Michael -- michael.schuster at oracle.com http://blogs.sun.com/recursion Recursion, n.: see ''Recursion''
we use the g++ compiler for this c++ executable g++ -v Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/specs Configured with: /builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) There are many files on a link line with some 3rd party libraries... g++ -m64 -fPIC /vob/adc/router/core/DiameterAdapter.o /vob/adc/router/core/DiameterAdapterThread.o \ /vob/adc/router/core/DiameterMessage.o /vob/adc/router/core/ServerGroup.o /vob/adc/router/core/RoundRobin.o \ /vob/adc/router/core/HashRouting.o /vob/adc/router/core/AlgorithmFactory.o /vob/adc/router/core/DiameterConfigException.o \ /vob/adc/router/core/DiameterException.o /vob/adc/router/core/DiameterMessageException.o /vob/adc/router/core/RoutingEngine.o \ . . . /vob/adc/router/framework/TraceLoggerThread.o \ -lsocket -lnsl -lpthread -L/vob/diameter/lib \ -L/vob/diameter/sctp/lib -L/vob/adc/router/thirdparty/boost/stage/lib \ -ldiameter -ldiamsctp -lboost_serialization -o ../bin/adc wr -----Original Message----- From: Michael Schuster [mailto:michael.schuster at oracle.com] Sent: Tuesday, May 11, 2010 9:36 AM To: William Reich Cc: dtrace-discuss at opensolaris.org Subject: Re: [dtrace-discuss] dtrace / c++ / lots of threads On 11.05.10 14:38, William Reich wrote:> as implied in the first email ( below ) , > the only thing that I see as different between this particular process > and any other > is that > a) the executable is 8.5 megs as it sits on the diskI don''t think this should be an issue ... but can you give some detail on how this executable is built?> b) the executable has at least 10 threads in it.the executable doesn''t have threads ;-) they''re a property of the running process, but I know what you mean: that shouldn''t be a problem, I just tried tracing firefox, which has more, and had no issue. Michael -- michael.schuster at oracle.com http://blogs.sun.com/recursion Recursion, n.: see ''Recursion''
On Tue, May 11, 2010 at 07:38:17AM +0200, Michael Schuster wrote:> On 10.05.10 21:01, William Reich wrote: > >only this process fails - > > > >./adc.d 24930 > >dtrace: failed to compile script ./adc.d: line 7: failed to grab > >process 24930Isn''t this what happens if a process is already being traced (e.g., by truss)? Nico --
truss was not being used in this simple test. Neither was gdb. wr -----Original Message----- Isn''t this what happens if a process is already being traced (e.g., by truss)? Nico -- -----Original Message----- From: dtrace-discuss-bounces at opensolaris.org [mailto:dtrace-discuss-bounces at opensolaris.org] On Behalf Of William Reich Sent: Tuesday, May 11, 2010 9:58 AM To: Michael Schuster Cc: dtrace-discuss at opensolaris.org Subject: Re: [dtrace-discuss] dtrace / c++ / lots of threads we use the g++ compiler for this c++ executable g++ -v Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/specs Configured with: /builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) There are many files on a link line with some 3rd party libraries... g++ -m64 -fPIC /vob/adc/router/core/DiameterAdapter.o /vob/adc/router/core/DiameterAdapterThread.o \ /vob/adc/router/core/DiameterMessage.o /vob/adc/router/core/ServerGroup.o /vob/adc/router/core/RoundRobin.o \ /vob/adc/router/core/HashRouting.o /vob/adc/router/core/AlgorithmFactory.o /vob/adc/router/core/DiameterConfigException.o \ /vob/adc/router/core/DiameterException.o /vob/adc/router/core/DiameterMessageException.o /vob/adc/router/core/RoutingEngine.o \ . . . /vob/adc/router/framework/TraceLoggerThread.o \ -lsocket -lnsl -lpthread -L/vob/diameter/lib \ -L/vob/diameter/sctp/lib -L/vob/adc/router/thirdparty/boost/stage/lib \ -ldiameter -ldiamsctp -lboost_serialization -o ../bin/adc wr -----Original Message----- From: Michael Schuster [mailto:michael.schuster at oracle.com] Sent: Tuesday, May 11, 2010 9:36 AM To: William Reich Cc: dtrace-discuss at opensolaris.org Subject: Re: [dtrace-discuss] dtrace / c++ / lots of threads On 11.05.10 14:38, William Reich wrote:> as implied in the first email ( below ) , > the only thing that I see as different between this particular process > and any other > is that > a) the executable is 8.5 megs as it sits on the diskI don''t think this should be an issue ... but can you give some detail on how this executable is built?> b) the executable has at least 10 threads in it.the executable doesn''t have threads ;-) they''re a property of the running process, but I know what you mean: that shouldn''t be a problem, I just tried tracing firefox, which has more, and had no issue. Michael -- michael.schuster at oracle.com http://blogs.sun.com/recursion Recursion, n.: see ''Recursion'' _______________________________________________ dtrace-discuss mailing list dtrace-discuss at opensolaris.org
On 11. mai 2010, at 19.27, William Reich wrote:> truss was not being used in this simple test. > Neither was gdb. >are you using watchmalloc or something else that utilize /proc ? Trond> wr > > > > -----Original Message----- > > Isn''t this what happens if a process is already being traced (e.g., by > truss)? > > Nico > -- > > -----Original Message----- > From: dtrace-discuss-bounces at opensolaris.org > [mailto:dtrace-discuss-bounces at opensolaris.org] On Behalf Of William > Reich > Sent: Tuesday, May 11, 2010 9:58 AM > To: Michael Schuster > Cc: dtrace-discuss at opensolaris.org > Subject: Re: [dtrace-discuss] dtrace / c++ / lots of threads > > we use the g++ compiler for this c++ executable > > g++ -v > Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/specs > Configured with: /builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure > --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as > --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ > --enable-shared > Thread model: posix > gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) > > There are many files on a link line with some 3rd party libraries... > > g++ -m64 -fPIC /vob/adc/router/core/DiameterAdapter.o > /vob/adc/router/core/DiameterAdapterThread.o \ > /vob/adc/router/core/DiameterMessage.o > /vob/adc/router/core/ServerGroup.o /vob/adc/router/core/RoundRobin.o \ > /vob/adc/router/core/HashRouting.o > /vob/adc/router/core/AlgorithmFactory.o > /vob/adc/router/core/DiameterConfigException.o \ > /vob/adc/router/core/DiameterException.o > /vob/adc/router/core/DiameterMessageException.o > /vob/adc/router/core/RoutingEngine.o \ > . > . > . > /vob/adc/router/framework/TraceLoggerThread.o \ > -lsocket -lnsl -lpthread -L/vob/diameter/lib \ > -L/vob/diameter/sctp/lib -L/vob/adc/router/thirdparty/boost/stage/lib \ > -ldiameter -ldiamsctp -lboost_serialization -o ../bin/adc > > > wr > > > -----Original Message----- > From: Michael Schuster [mailto:michael.schuster at oracle.com] > Sent: Tuesday, May 11, 2010 9:36 AM > To: William Reich > Cc: dtrace-discuss at opensolaris.org > Subject: Re: [dtrace-discuss] dtrace / c++ / lots of threads > > On 11.05.10 14:38, William Reich wrote: >> as implied in the first email ( below ) , >> the only thing that I see as different between this particular process >> and any other >> is that >> a) the executable is 8.5 megs as it sits on the disk > > I don''t think this should be an issue ... but can you give some detail > on > how this executable is built? > >> b) the executable has at least 10 threads in it. > > the executable doesn''t have threads ;-) they''re a property of the > running > process, but I know what you mean: that shouldn''t be a problem, I just > tried tracing firefox, which has more, and had no issue. > > Michael > -- > michael.schuster at oracle.com http://blogs.sun.com/recursion > Recursion, n.: see ''Recursion'' > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org
as far as I know - no again, any other executable , say "hello world" , works with dtrace just fine. Only this one particular executable is not working with dtrace. wr -----Original Message----- From: Trond Norbye [mailto:trond.norbye at gmail.com] Sent: Tuesday, May 11, 2010 1:32 PM To: William Reich Cc: dtrace-discuss at opensolaris.org Subject: Re: [dtrace-discuss] dtrace / c++ / lots of threads On 11. mai 2010, at 19.27, William Reich wrote:> truss was not being used in this simple test. > Neither was gdb. >are you using watchmalloc or something else that utilize /proc ? Trond> wr > > > > -----Original Message----- > > Isn''t this what happens if a process is already being traced (e.g., by > truss)? > > Nico > -- > > -----Original Message----- > From: dtrace-discuss-bounces at opensolaris.org > [mailto:dtrace-discuss-bounces at opensolaris.org] On Behalf Of William > Reich > Sent: Tuesday, May 11, 2010 9:58 AM > To: Michael Schuster > Cc: dtrace-discuss at opensolaris.org > Subject: Re: [dtrace-discuss] dtrace / c++ / lots of threads > > we use the g++ compiler for this c++ executable > > g++ -v > Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/specs > Configured with:/builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure> --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as > --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ > --enable-shared > Thread model: posix > gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) > > There are many files on a link line with some 3rd party libraries... > > g++ -m64 -fPIC /vob/adc/router/core/DiameterAdapter.o > /vob/adc/router/core/DiameterAdapterThread.o \ > /vob/adc/router/core/DiameterMessage.o > /vob/adc/router/core/ServerGroup.o /vob/adc/router/core/RoundRobin.o \ > /vob/adc/router/core/HashRouting.o > /vob/adc/router/core/AlgorithmFactory.o > /vob/adc/router/core/DiameterConfigException.o \ > /vob/adc/router/core/DiameterException.o > /vob/adc/router/core/DiameterMessageException.o > /vob/adc/router/core/RoutingEngine.o \ > . > . > . > /vob/adc/router/framework/TraceLoggerThread.o \ > -lsocket -lnsl -lpthread -L/vob/diameter/lib \ > -L/vob/diameter/sctp/lib -L/vob/adc/router/thirdparty/boost/stage/lib\> -ldiameter -ldiamsctp -lboost_serialization -o ../bin/adc > > > wr > > > -----Original Message----- > From: Michael Schuster [mailto:michael.schuster at oracle.com] > Sent: Tuesday, May 11, 2010 9:36 AM > To: William Reich > Cc: dtrace-discuss at opensolaris.org > Subject: Re: [dtrace-discuss] dtrace / c++ / lots of threads > > On 11.05.10 14:38, William Reich wrote: >> as implied in the first email ( below ) , >> the only thing that I see as different between this particularprocess>> and any other >> is that >> a) the executable is 8.5 megs as it sits on the disk > > I don''t think this should be an issue ... but can you give some detail > on > how this executable is built? > >> b) the executable has at least 10 threads in it. > > the executable doesn''t have threads ;-) they''re a property of the > running > process, but I know what you mean: that shouldn''t be a problem, I just> tried tracing firefox, which has more, and had no issue. > > Michael > -- > michael.schuster at oracle.com http://blogs.sun.com/recursion > Recursion, n.: see ''Recursion'' > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org
Yosef Lev (Sun Labs, Oracle)
2010-May-11 19:00 UTC
[dtrace-discuss] dtrace / c++ / lots of threads
I''m not sure what the problem might be (except for the process being traced by another program), but have you tried letting DTrace run the executable for you (with the "-c" switch)? To do that, you''ll have to replace $1 with $target in your DTrace script, and then run it as follows: dtrace -s <script file> -c ''<command to run your executable>'' DTrace will create a process to run the command specified after the ''-c'' switch, assign the pid to $target and pass it to your script. Cheers, Yossi William Reich wrote:> as far as I know - no > > again, any other executable , say "hello world" , works with dtrace just > fine. > > Only this one particular executable is not working with dtrace. > > wr > > -----Original Message----- > From: Trond Norbye [mailto:trond.norbye at gmail.com] > Sent: Tuesday, May 11, 2010 1:32 PM > To: William Reich > Cc: dtrace-discuss at opensolaris.org > Subject: Re: [dtrace-discuss] dtrace / c++ / lots of threads > > > On 11. mai 2010, at 19.27, William Reich wrote: > > >> truss was not being used in this simple test. >> Neither was gdb. >> >> > > are you using watchmalloc or something else that utilize /proc ? > > Trond > > > >> wr >> >> >> >> -----Original Message----- >> >> Isn''t this what happens if a process is already being traced (e.g., by >> truss)? >> >> Nico >> -- >> >> -----Original Message----- >> From: dtrace-discuss-bounces at opensolaris.org >> [mailto:dtrace-discuss-bounces at opensolaris.org] On Behalf Of William >> Reich >> Sent: Tuesday, May 11, 2010 9:58 AM >> To: Michael Schuster >> Cc: dtrace-discuss at opensolaris.org >> Subject: Re: [dtrace-discuss] dtrace / c++ / lots of threads >> >> we use the g++ compiler for this c++ executable >> >> g++ -v >> Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/specs >> Configured with: >> > /builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure > >> --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as >> --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ >> --enable-shared >> Thread model: posix >> gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) >> >> There are many files on a link line with some 3rd party libraries... >> >> g++ -m64 -fPIC /vob/adc/router/core/DiameterAdapter.o >> /vob/adc/router/core/DiameterAdapterThread.o \ >> /vob/adc/router/core/DiameterMessage.o >> /vob/adc/router/core/ServerGroup.o /vob/adc/router/core/RoundRobin.o \ >> /vob/adc/router/core/HashRouting.o >> /vob/adc/router/core/AlgorithmFactory.o >> /vob/adc/router/core/DiameterConfigException.o \ >> /vob/adc/router/core/DiameterException.o >> /vob/adc/router/core/DiameterMessageException.o >> /vob/adc/router/core/RoutingEngine.o \ >> . >> . >> . >> /vob/adc/router/framework/TraceLoggerThread.o \ >> -lsocket -lnsl -lpthread -L/vob/diameter/lib \ >> -L/vob/diameter/sctp/lib -L/vob/adc/router/thirdparty/boost/stage/lib >> > \ > >> -ldiameter -ldiamsctp -lboost_serialization -o ../bin/adc >> >> >> wr >> >> >> -----Original Message----- >> From: Michael Schuster [mailto:michael.schuster at oracle.com] >> Sent: Tuesday, May 11, 2010 9:36 AM >> To: William Reich >> Cc: dtrace-discuss at opensolaris.org >> Subject: Re: [dtrace-discuss] dtrace / c++ / lots of threads >> >> On 11.05.10 14:38, William Reich wrote: >> >>> as implied in the first email ( below ) , >>> the only thing that I see as different between this particular >>> > process > >>> and any other >>> is that >>> a) the executable is 8.5 megs as it sits on the disk >>> >> I don''t think this should be an issue ... but can you give some detail >> on >> how this executable is built? >> >> >>> b) the executable has at least 10 threads in it. >>> >> the executable doesn''t have threads ;-) they''re a property of the >> running >> process, but I know what you mean: that shouldn''t be a problem, I just >> > > >> tried tracing firefox, which has more, and had no issue. >> >> Michael >> -- >> michael.schuster at oracle.com http://blogs.sun.com/recursion >> Recursion, n.: see ''Recursion'' >> _______________________________________________ >> dtrace-discuss mailing list >> dtrace-discuss at opensolaris.org >> _______________________________________________ >> dtrace-discuss mailing list >> dtrace-discuss at opensolaris.org >> > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org >
yes, this was attempted. The program ran for a short time ( 2 seconds ? ) and then just stopped - back to the prompt. -----Original Message----- From: Yosef Lev (Sun Labs, Oracle) [mailto:yossi.lev at oracle.com] Sent: Tuesday, May 11, 2010 3:01 PM To: William Reich Cc: Trond Norbye; dtrace-discuss at opensolaris.org Subject: Re: [dtrace-discuss] dtrace / c++ / lots of threads I''m not sure what the problem might be (except for the process being traced by another program), but have you tried letting DTrace run the executable for you (with the "-c" switch)? To do that, you''ll have to replace $1 with $target in your DTrace script, and then run it as follows: dtrace -s <script file> -c ''<command to run your executable>'' DTrace will create a process to run the command specified after the ''-c'' switch, assign the pid to $target and pass it to your script. Cheers, Yossi William Reich wrote:> as far as I know - no > > again, any other executable , say "hello world" , works with dtracejust> fine. > > Only this one particular executable is not working with dtrace. > > wr > > -----Original Message----- > From: Trond Norbye [mailto:trond.norbye at gmail.com] > Sent: Tuesday, May 11, 2010 1:32 PM > To: William Reich > Cc: dtrace-discuss at opensolaris.org > Subject: Re: [dtrace-discuss] dtrace / c++ / lots of threads > > > On 11. mai 2010, at 19.27, William Reich wrote: > > >> truss was not being used in this simple test. >> Neither was gdb. >> >> > > are you using watchmalloc or something else that utilize /proc ? > > Trond > > > >> wr >> >> >> >> -----Original Message----- >> >> Isn''t this what happens if a process is already being traced (e.g.,by>> truss)? >> >> Nico >> -- >> >> -----Original Message----- >> From: dtrace-discuss-bounces at opensolaris.org >> [mailto:dtrace-discuss-bounces at opensolaris.org] On Behalf Of William >> Reich >> Sent: Tuesday, May 11, 2010 9:58 AM >> To: Michael Schuster >> Cc: dtrace-discuss at opensolaris.org >> Subject: Re: [dtrace-discuss] dtrace / c++ / lots of threads >> >> we use the g++ compiler for this c++ executable >> >> g++ -v >> Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/specs >> Configured with: >> > /builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure > >> --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as >> --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ >> --enable-shared >> Thread model: posix >> gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) >> >> There are many files on a link line with some 3rd party libraries... >> >> g++ -m64 -fPIC /vob/adc/router/core/DiameterAdapter.o >> /vob/adc/router/core/DiameterAdapterThread.o \ >> /vob/adc/router/core/DiameterMessage.o >> /vob/adc/router/core/ServerGroup.o /vob/adc/router/core/RoundRobin.o\>> /vob/adc/router/core/HashRouting.o >> /vob/adc/router/core/AlgorithmFactory.o >> /vob/adc/router/core/DiameterConfigException.o \ >> /vob/adc/router/core/DiameterException.o >> /vob/adc/router/core/DiameterMessageException.o >> /vob/adc/router/core/RoutingEngine.o \ >> . >> . >> . >> /vob/adc/router/framework/TraceLoggerThread.o \ >> -lsocket -lnsl -lpthread -L/vob/diameter/lib \ >> -L/vob/diameter/sctp/lib -L/vob/adc/router/thirdparty/boost/stage/lib >> > \ > >> -ldiameter -ldiamsctp -lboost_serialization -o ../bin/adc >> >> >> wr >> >> >> -----Original Message----- >> From: Michael Schuster [mailto:michael.schuster at oracle.com] >> Sent: Tuesday, May 11, 2010 9:36 AM >> To: William Reich >> Cc: dtrace-discuss at opensolaris.org >> Subject: Re: [dtrace-discuss] dtrace / c++ / lots of threads >> >> On 11.05.10 14:38, William Reich wrote: >> >>> as implied in the first email ( below ) , >>> the only thing that I see as different between this particular >>> > process > >>> and any other >>> is that >>> a) the executable is 8.5 megs as it sits on the disk >>> >> I don''t think this should be an issue ... but can you give somedetail>> on >> how this executable is built? >> >> >>> b) the executable has at least 10 threads in it. >>> >> the executable doesn''t have threads ;-) they''re a property of the >> running >> process, but I know what you mean: that shouldn''t be a problem, Ijust>> > > >> tried tracing firefox, which has more, and had no issue. >> >> Michael >> -- >> michael.schuster at oracle.com http://blogs.sun.com/recursion >> Recursion, n.: see ''Recursion'' >> _______________________________________________ >> dtrace-discuss mailing list >> dtrace-discuss at opensolaris.org >> _______________________________________________ >> dtrace-discuss mailing list >> dtrace-discuss at opensolaris.org >> > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org >
On 11.05.10 20:26, William Reich wrote:> as far as I know - no > > again, any other executable , say "hello world" , works with dtrace just > fine. > > Only this one particular executable is not working with dtrace.IIRC, it was a fairly complex beast. can you reduce it to the minimal set that still exhibits this behaviour, maybe thereby showing the difference that causes this to happpen? Michael -- michael.schuster at oracle.com http://blogs.sun.com/recursion Recursion, n.: see ''Recursion''