Menu
▾
▴
valgrind-users
|
From: Joerg B. <j....@we...> - 2003-04-22 09:25:07
|
Nicholas Nethercote <nj...@ca...> schrieb am 22.04.03 11:18:30:
>
> On Tue, 22 Apr 2003, Joerg Beyer wrote:
>
> > > If so... your program isn't statically linked? Valgrind doesn't work with
> > > statically linked apps. Is Valgrind starting up -- ie. you're getting the
> >
> > ok, that may be the part I was missing. some parts are linked as archive
> > (e.g. python.a). This is not possible? If so, excuse for missing this part
> > of the documentation.
>
> No, that should be fine. It's only a problem if the whole program is
> statically linked, in which case Valgrind won't even start up.
>
> > > Have you tried Valgrind with other programs, eg. small test ones that have
> > > deliberate errors in them? What version of Valgrind are you using?
> >
> > yes, but other, smaller programms work as expected and detect the errors.
> > valgrinds version is 1.9.5
>
> Hmm, very strange. Are you certain that the obvious error you inserted is
> being executed? Maybe #include memcheck.h and insert a call to
yes, I have picked a place in the source that is executed on inititalization
of the apache module. I even put debug messages before and after that
place (both appeared in the logfile).
> VALGRIND_DO_LEAK_CHECK and see if that runs, to make sure that (a) the
> code is being executed and (b) that Valgrind is seeing the code. I can't
> think why Valgrind wouldn't be seeing the code, but this behaviour is
> weird.
>
> Apart from that, I'm all out of ideas for the moment, sorry.
>
thanks for the guesses. I try to strip the complex code
simpler code and post again if I am able to reduce it so
something simple enough.
Joerg
|
|
From: Joerg B. <j....@we...> - 2003-04-22 09:56:17
|
Nicholas Nethercote <nj...@ca...> schrieb am 22.04.03 11:18:30:
>
> On Tue, 22 Apr 2003, Joerg Beyer wrote:
>
> Hmm, very strange. Are you certain that the obvious error you inserted is
> being executed? Maybe #include memcheck.h and insert a call to
> VALGRIND_DO_LEAK_CHECK and see if that runs, to make sure that (a) the
> code is being executed and (b) that Valgrind is seeing the code. I can't
> think why Valgrind wouldn't be seeing the code, but this behaviour is
> weird.
>
> Apart from that, I'm all out of ideas for the moment, sorry.
ok, apache seems to close the filedescriptor - if I use
--logsocket, then I could see the valgrind output.
Please excuse, that I have not tried that _before_ posting.
Now I have loads of things to check and possibly fix :-)
thanks for your help
Joerg
|
|
From: Nicholas N. <nj...@ca...> - 2003-04-22 10:55:54
|
On Tue, 22 Apr 2003, Joerg Beyer wrote: > ok, apache seems to close the filedescriptor - if I use > --logsocket, then I could see the valgrind output. That's a bit odd... Valgrind checks close() syscalls for exactly this case. Did you not get any message like this: Warning: client attempted to close Valgrind's logfile fd (x). Use --logfile-fd=<number> to select an alternative logfile fd. ? N |
|
From: Crispin F. <cr...@th...> - 2003-04-22 11:06:26
|
On Tue, 2003-04-22 at 11:55, Nicholas Nethercote wrote: > On Tue, 22 Apr 2003, Joerg Beyer wrote: > > > ok, apache seems to close the filedescriptor - if I use > > --logsocket, then I could see the valgrind output. > > That's a bit odd... Valgrind checks close() syscalls for exactly this > case. Did you not get any message like this: > > Warning: client attempted to close Valgrind's logfile fd (x). > Use --logfile-fd=<number> to select an alternative logfile fd. I have a feeling that Apache will open it's error log file, then use dup2() to map stderr to that file. I get valgrind errors in my apache error log file when I run it, perhaps the check for valgrind's logfile should be in the dup2() system call as well? Crispin |
|
From: Alex I. <ale...@in...> - 2003-04-22 16:04:25
|
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Hi all, <p>I hope someone can give me a hand here - I am trying to build Valgrind 1.9.5 on RedHat 8 with glibc 2.3.2-4.80 installed. When building, I get the following error: <p>make[3]: Entering directory `/home/agi/tmp/valgrind-1.9.5/corecheck/tests' <br>gcc -Winline -Wall -Wshadow -g -o pth_atfork1 pth_atfork1.o -lpthread <br>pth_atfork1.o: In function `main': <br>/home/agi/tmp/valgrind-1.9.5/corecheck/tests/pth_atfork1.c:68: undefined reference to `pthread_atfork' <br>collect2: ld returned 1 exit status <br>make[3]: *** [pth_atfork1] Error 1 <br>make[3]: Leaving directory `/home/agi/tmp/valgrind-1.9.5/corecheck/tests' <p>Pthread library, bith static and dynamic, do have pthread_atfork symbol defined. And the path to /usr/lib is the firs in LD_LIBRARY_PATH. Any suggestions for me? Thanks beforehand! <p>Alex <pre>-- Alex G. Ivershen Inet Technologies, Inc. Network Products Dept. 1500 N. Greenville Ave. Inet Technologies Inc. Richardson, TX 75081 Phone: +1-469-330-4295 USA "Black Holes are where God divided by zero"</pre> </html> |
|
From: Nicholas N. <nj...@ca...> - 2003-04-23 07:51:32
|
On Tue, 22 Apr 2003, Alex Ivershen wrote: > I hope someone can give me a hand here - I am trying to build Valgrind > 1.9.5 on RedHat 8 with glibc 2.3.2-4.80 installed.=A0 When building, I ge= t > the following error: > > make[3]: Entering directory > `/home/agi/tmp/valgrind-1.9.5/corecheck/tests' > gcc=A0=A0 -Winline -Wall -Wshadow -g=A0=A0 -o pth_atfork1=A0 pth_atfork1.= o > -lpthread > pth_atfork1.o: In function `main': > /home/agi/tmp/valgrind-1.9.5/corecheck/tests/pth_atfork1.c:68: undefined > reference to `pthread_atfork' > collect2: ld returned 1 exit status > make[3]: *** [pth_atfork1] Error 1 > make[3]: Leaving directory `/home/agi/tmp/valgrind-1.9.5/corecheck/tests' > > Pthread library, bith static and dynamic, do have pthread_atfork symbol > defined. And the path to /usr/lib is the firs in LD_LIBRARY_PATH. Any > suggestions for me? Thanks beforehand! That's weird. What's the output of: nm /usr/lib/libpthread.so | grep pthread_atfork ? Does it define pthread_atfork? Can you compile any program that uses pthread_atfork? A temporary hack to workaround is to change the SUBDIRS variable in valgrind/memcheck/Makefile.in from this: SUBDIRS =3D . tests docs to this: SUBDIRS =3D . docs The 'tests' directory contains the regression tests, and missing those won't cause you any grief. N |
|
From: Alex I. <ale...@in...> - 2003-04-24 19:54:26
Attachments:
main.cpp
|
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Hi all, <p>I am observing a strange behaviour while trying to valgrind my mutlithreaded programs. I wrote a trivial test program with two threads and the behaviour replicates what I am seeing in my apps. Here is the scenario - application spawns two threads. First one opens a socket and is doing blocking recv(). Then the second one is spawned to do something else. Works just fine without valgrind. <p>What happens in valgrind, when the first thread, socket listener, is spawned, it executes in the context of main thread. This causes the main thread to block on recv(), and as consequence the program never goes any further, not spawning the second thread, not doing anything. I do know you are using your own substitute for pthreads library, but I cannot imagine that you mutilating it so much as to collapse all application threads into one. <p>I am using RH8 Linux with glibc-2.3.2-4.80, kernel 2.4.18-26.8.0smp, compiling with gcc 2.95.3 (can't go higher because of source code dependencies issues). I am including source code for the little test program and backtrace after it's stuck in recv() - you can see that everything is in one thread, and gdb does not show any more threads whatsoever. <p>So, if you could solve the mystery for me, it will be much appreciated! I cannot wait to get my hands on all the features that the manual talks about - and from general Linux community buzz you guys are much better then Rational Purify. <p>Regards, <br>Alex <p>(gdb) bt <br>#0 0x400bb262 in vgPlain_do_syscall () from /home/agi/linux/lib/valgrind/valgrind.so <br>#1 0x400a8c1e in vgIntercept_recv (s=4, buf=0x40e53b10, len=1000, flags=0) at vg_intercept.c:152 <br>#2 0x400a8c34 in recv (s=4, buf=0x40e53b10, len=1000, flags=0) at vg_intercept.c:157 <br>#3 0x08048790 in ListenerStart(void*) (pParm=0x0) at main.cpp:59 <br>#4 0x4013a58d in thread_wrapper (info=0xfffffe00) at vg_libpthread.c:671 <br>#5 0x4009ab80 in do__apply_in_new_thread_bogusRA () at vg_scheduler.c:2155 <br>#6 0x08048695 in main () at main.cpp:25 <br>#7 0x401794ad in __libc_start_main () from /lib/libc.so.6 <pre>-- Alex G. Ivershen Inet Technologies, Inc. Network Products Dept. 1500 N. Greenville Ave. Inet Technologies Inc. Richardson, TX 75081 Phone: +1-469-330-4295 USA "Black Holes are where God divided by zero"</pre> </html> |
|
From: Julian S. <js...@ac...> - 2003-04-24 20:22:26
|
Sigh ... Sure, our threading library normally handles this fine. However there are big problems on dealing with threading in systems with glibc 2.3.2 and later, and this is one of them. Are you able to build / run your app on a distro with glibc of 2.3.1 or earlier? That might help. (Test with your tiny test program first ...) J On Thursday 24 April 2003 8:54 pm, Alex Ivershen wrote: > <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> > <html> > Hi all, > <p>I am observing a strange behaviour while trying to valgrind my > mutlithreaded programs. I wrote a trivial test program with two > threads and the behaviour replicates what I am seeing in my apps. Here is > the scenario - application spawns two threads. First one opens a socket and > is doing blocking recv(). Then the second one is spawned to do > something else. Works just fine without valgrind. > <p>What happens in valgrind, when the first thread, socket listener, is > spawned, it executes in the context of main thread. This causes the main > thread to block on recv(), and as consequence the program never goes any > further, not spawning the second thread, not doing anything. I do > know you are using your own substitute for pthreads library, but I cannot > imagine that you mutilating it so much as to collapse all application > threads into one. > <p>I am using RH8 Linux with glibc-2.3.2-4.80, kernel 2.4.18-26.8.0smp, > compiling with gcc 2.95.3 (can't go higher because of source code > dependencies issues). I am including source code for the little test > program and backtrace after it's stuck in recv() - you can see that > everything is in one thread, and gdb does not show any more threads > whatsoever. > <p>So, if you could solve the mystery for me, it will be much appreciated! > I cannot wait to get my hands on all the features that the manual talks > about - and from general Linux community buzz you guys are much better > then Rational Purify. > <p>Regards, > <br>Alex > <p>(gdb) bt > <br>#0 0x400bb262 in vgPlain_do_syscall () from > /home/agi/linux/lib/valgrind/valgrind.so <br>#1 0x400a8c1e in > vgIntercept_recv (s=4, buf=0x40e53b10, len=1000, flags=0) at > vg_intercept.c:152 > <br>#2 0x400a8c34 in recv (s=4, buf=0x40e53b10, len=1000, flags=0) > at vg_intercept.c:157 > <br>#3 0x08048790 in ListenerStart(void*) (pParm=0x0) at main.cpp:59 > <br>#4 0x4013a58d in thread_wrapper (info=0xfffffe00) at > vg_libpthread.c:671 <br>#5 0x4009ab80 in > do__apply_in_new_thread_bogusRA () at vg_scheduler.c:2155 <br>#6 > 0x08048695 in main () at main.cpp:25 > <br>#7 0x401794ad in __libc_start_main () from /lib/libc.so.6 > <pre>-- > Alex G. > Ivershen & >nbsp;   >; Inet Technologies, Inc. Network Products > Dept. &nbs >p; 1500 N. Greenville > Ave. Inet Technologies > Inc.   >; Richardson, TX 75081 > Phone: > +1-469-330-4295 > USA > > "Black Holes are where God divided by zero"</pre> > </html> |
|
From: Todd R. <ric...@pr...> - 2003-04-24 20:38:16
|
Your code should work fine on a glibc 2.3.1 system such as plain vanilla,
freshly installed Redhat 8. If you require Redhat 9 or patches to 8(which
may upgrade to 2.3.2) , you will have to wait for a valgrind update
Todd
----- Original Message -----
From: "Julian Seward" <js...@ac...>
To: "Alex Ivershen" <ale...@in...>; "Nicholas Nethercote"
<nj...@ca...>
Cc: <val...@li...>
Sent: Thursday, April 24, 2003 1:22 PM
Subject: Re: [Valgrind-users] Valgrind'ing multiple threads
>
> Sigh ...
>
> Sure, our threading library normally handles this fine. However
> there are big problems on dealing with threading in systems
> with glibc 2.3.2 and later, and this is one of them.
>
> Are you able to build / run your app on a distro with
> glibc of 2.3.1 or earlier? That might help. (Test with
> your tiny test program first ...)
>
> J
>
>
> On Thursday 24 April 2003 8:54 pm, Alex Ivershen wrote:
> > <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
> > <html>
> > Hi all,
> > <p>I am observing a strange behaviour while trying to valgrind my
> > mutlithreaded programs. I wrote a trivial test program with two
> > threads and the behaviour replicates what I am seeing in my apps. Here
is
> > the scenario - application spawns two threads. First one opens a socket
and
> > is doing blocking recv(). Then the second one is spawned to do
> > something else. Works just fine without valgrind.
> > <p>What happens in valgrind, when the first thread, socket listener, is
> > spawned, it executes in the context of main thread. This causes the main
> > thread to block on recv(), and as consequence the program never goes any
> > further, not spawning the second thread, not doing anything. I do
> > know you are using your own substitute for pthreads library, but I
cannot
> > imagine that you mutilating it so much as to collapse all application
> > threads into one.
> > <p>I am using RH8 Linux with glibc-2.3.2-4.80, kernel 2.4.18-26.8.0smp,
> > compiling with gcc 2.95.3 (can't go higher because of source code
> > dependencies issues). I am including source code for the little test
> > program and backtrace after it's stuck in recv() - you can see that
> > everything is in one thread, and gdb does not show any more threads
> > whatsoever.
> > <p>So, if you could solve the mystery for me, it will be much
appreciated!
> > I cannot wait to get my hands on all the features that the manual talks
> > about - and from general Linux community buzz you guys are much better
> > then Rational Purify.
> > <p>Regards,
> > <br>Alex
> > <p>(gdb) bt
> > <br>#0 0x400bb262 in vgPlain_do_syscall () from
> > /home/agi/linux/lib/valgrind/valgrind.so <br>#1 0x400a8c1e in
> > vgIntercept_recv (s=4, buf=0x40e53b10, len=1000, flags=0) at
> > vg_intercept.c:152
> > <br>#2 0x400a8c34 in recv (s=4, buf=0x40e53b10, len=1000, flags=0)
> > at vg_intercept.c:157
> > <br>#3 0x08048790 in ListenerStart(void*) (pParm=0x0) at
main.cpp:59
> > <br>#4 0x4013a58d in thread_wrapper (info=0xfffffe00) at
> > vg_libpthread.c:671 <br>#5 0x4009ab80 in
> > do__apply_in_new_thread_bogusRA () at vg_scheduler.c:2155 <br>#6
> > 0x08048695 in main () at main.cpp:25
> > <br>#7 0x401794ad in __libc_start_main () from /lib/libc.so.6
> > <pre>--
> > Alex G.
> >
Ivershen &
>
>nbsp; &nbs
p
> >; Inet Technologies, Inc. Network Products
> >
Dept. &nbs
> >p; 1500 N.
Greenville
> > Ave. Inet Technologies
> >
Inc.  
> >; Richardson, TX
75081
> > Phone:
> >
+1-469-330-4295
> > USA
> >
> > "Black Holes are where God divided by zero"</pre>
> > </html>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
|
|
From: Alex I. <ale...@in...> - 2003-04-24 21:32:30
|
R3V5cywNCg0KWWVwLCAgdGhhdCB3YXMgaXQuIEkga2luZGEgaGFkIGEgc3VzcGljaW9uIHRo YXQgaXQgd2FzIHRoZSBuZXdlciBnbGliYy4NCkV2ZXJ5dGhpbmcgd29ya2VkIHBlcmZlY3Rs eSBvbiBmcmVzaCBSZWRIYXQuIFNvLCBkbyB5b3UgZ3V5cyBoYXZlIGFueSBpZGVhDQphYm91 dCB0aW1lZnJhbWUgd2hlbiBnbGliYyAyLjMuMiB3aWxsIGJlIHN1cHBvcnRlZD8gSnVzdCBj dXJpb3VzIC4uLg0KDQpTb3JyeSBmb3Igb2ZmLXRvcGljLCBidXQgSSB3b3VsZCBsaWtlIHRv IGFzayBWYWxncmluZCB1c2VycyBhIHF1ZXN0aW9uIC0gbm8NCmRvdWJ0IHNvbWUgb2YgeW91 IGhhdmUgcnVuIGludG8gdGhpcy4gSSBhbSBkZWVwbHkgaW50ZXJlc3RlZCBpbiBmaW5kaW5n IGENCnBlcmZvcm1hbmNlIHByb2ZpbGVyIHRoYXQgd29ya3Mgd2l0aG91dCBjb2RlIHJlY29t cGlsYXRpb24uIEdwcm9mIGlzIGdyZWF0LCBidXQNCi4uLiBjYW4ndCB1c2UgaXQuIElzIHRo ZXJlIGFueXRoaW5nIG91dCB0aGVyZSBmb3IgTGludXggdGhhdCB3b3JrcyBsaWtlDQp2YWxn cmluZCAtIG9uIGV4ZWN1dGFsYmxlcz8gT3IgYXQgbGVhc3Qgb24gb2JqZWN0IGZpbGVzPyBJ IHdvdWxkIHRydWx5DQphcHByZWNpYXRlIGFueSBmZWVkYmFjay4NCg0KQmlnIHNob3V0b3V0 IHRvIFZhbGdyaW5kIGRldmVsb3BlcnMgLSB5b3UgaGF2ZSBkb25lIGFuZCBhcmUgZG9pbmcg YW1hemluZyBqb2IhDQpBbGV4DQoNCg0KVG9kZCBSaWNobW9uZCB3cm90ZToNCg0KPiBZb3Vy IGNvZGUgc2hvdWxkIHdvcmsgZmluZSBvbiBhIGdsaWJjIDIuMy4xIHN5c3RlbSBzdWNoIGFz IHBsYWluIHZhbmlsbGEsDQo+IGZyZXNobHkgaW5zdGFsbGVkIFJlZGhhdCA4LiBJZiB5b3Ug cmVxdWlyZSBSZWRoYXQgOSBvciBwYXRjaGVzIHRvIDgod2hpY2gNCj4gbWF5IHVwZ3JhZGUg dG8gMi4zLjIpICwgeW91IHdpbGwgaGF2ZSB0byB3YWl0IGZvciBhIHZhbGdyaW5kIHVwZGF0 ZQ0KPiAgICAgVG9kZA0KPg0KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZy b206ICJKdWxpYW4gU2V3YXJkIiA8anNld2FyZEBhY20ub3JnPg0KPiBUbzogIkFsZXggSXZl cnNoZW4iIDxhbGV4Lml2ZXJzaGVuQGluZXQuY29tPjsgIk5pY2hvbGFzIE5ldGhlcmNvdGUi DQo+IDxuam4yNUBjYW0uYWMudWs+DQo+IENjOiA8dmFsZ3JpbmQtdXNlcnNAbGlzdHMuc291 cmNlZm9yZ2UubmV0Pg0KPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMjQsIDIwMDMgMToyMiBQ TQ0KPiBTdWJqZWN0OiBSZTogW1ZhbGdyaW5kLXVzZXJzXSBWYWxncmluZCdpbmcgbXVsdGlw bGUgdGhyZWFkcw0KPg0KPiA+DQo+ID4gU2lnaCAuLi4NCj4gPg0KPiA+IFN1cmUsIG91ciB0 aHJlYWRpbmcgbGlicmFyeSBub3JtYWxseSBoYW5kbGVzIHRoaXMgZmluZS4gIEhvd2V2ZXIN Cj4gPiB0aGVyZSBhcmUgYmlnIHByb2JsZW1zIG9uIGRlYWxpbmcgd2l0aCB0aHJlYWRpbmcg aW4gc3lzdGVtcw0KPiA+IHdpdGggZ2xpYmMgMi4zLjIgYW5kIGxhdGVyLCBhbmQgdGhpcyBp cyBvbmUgb2YgdGhlbS4NCj4gPg0KPiA+IEFyZSB5b3UgYWJsZSB0byBidWlsZCAvIHJ1biB5 b3VyIGFwcCBvbiBhIGRpc3RybyB3aXRoDQo+ID4gZ2xpYmMgb2YgMi4zLjEgb3IgZWFybGll cj8gIFRoYXQgbWlnaHQgaGVscC4gIChUZXN0IHdpdGgNCj4gPiB5b3VyIHRpbnkgdGVzdCBw cm9ncmFtIGZpcnN0IC4uLikNCj4gPg0KPiA+IEoNCj4gPg0KPiA+DQo+ID4gT24gVGh1cnNk YXkgMjQgQXByaWwgMjAwMyA4OjU0IHBtLCBBbGV4IEl2ZXJzaGVuIHdyb3RlOg0KPiA+ID4g PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9u YWwvL2VuIj4NCj4gPiA+IDxodG1sPg0KPiA+ID4gSGkgYWxsLA0KPiA+ID4gPHA+SSBhbSBv YnNlcnZpbmcgYSBzdHJhbmdlIGJlaGF2aW91ciB3aGlsZSB0cnlpbmcgdG8gdmFsZ3JpbmQg bXkNCj4gPiA+IG11dGxpdGhyZWFkZWQgcHJvZ3JhbXMuJm5ic3A7IEkgd3JvdGUgYSB0cml2 aWFsIHRlc3QgcHJvZ3JhbSB3aXRoIHR3bw0KPiA+ID4gdGhyZWFkcyBhbmQgdGhlIGJlaGF2 aW91ciByZXBsaWNhdGVzIHdoYXQgSSBhbSBzZWVpbmcgaW4gbXkgYXBwcy4gSGVyZQ0KPiBp cw0KPiA+ID4gdGhlIHNjZW5hcmlvIC0gYXBwbGljYXRpb24gc3Bhd25zIHR3byB0aHJlYWRz LiBGaXJzdCBvbmUgb3BlbnMgYSBzb2NrZXQNCj4gYW5kDQo+ID4gPiBpcyBkb2luZyBibG9j a2luZyByZWN2KCkuJm5ic3A7IFRoZW4gdGhlIHNlY29uZCBvbmUgaXMgc3Bhd25lZCB0byBk bw0KPiA+ID4gc29tZXRoaW5nIGVsc2UuJm5ic3A7IFdvcmtzIGp1c3QgZmluZSB3aXRob3V0 IHZhbGdyaW5kLg0KPiA+ID4gPHA+V2hhdCBoYXBwZW5zIGluIHZhbGdyaW5kLCB3aGVuIHRo ZSBmaXJzdCB0aHJlYWQsIHNvY2tldCBsaXN0ZW5lciwgaXMNCj4gPiA+IHNwYXduZWQsIGl0 IGV4ZWN1dGVzIGluIHRoZSBjb250ZXh0IG9mIG1haW4gdGhyZWFkLiBUaGlzIGNhdXNlcyB0 aGUgbWFpbg0KPiA+ID4gdGhyZWFkIHRvIGJsb2NrIG9uIHJlY3YoKSwgYW5kIGFzIGNvbnNl cXVlbmNlIHRoZSBwcm9ncmFtIG5ldmVyIGdvZXMgYW55DQo+ID4gPiBmdXJ0aGVyLCBub3Qg c3Bhd25pbmcgdGhlIHNlY29uZCB0aHJlYWQsIG5vdCBkb2luZyBhbnl0aGluZy4mbmJzcDsg SSBkbw0KPiA+ID4ga25vdyB5b3UgYXJlIHVzaW5nIHlvdXIgb3duIHN1YnN0aXR1dGUgZm9y IHB0aHJlYWRzIGxpYnJhcnksIGJ1dCBJDQo+IGNhbm5vdA0KPiA+ID4gaW1hZ2luZSB0aGF0 IHlvdSBtdXRpbGF0aW5nIGl0IHNvIG11Y2ggYXMgdG8gY29sbGFwc2UgYWxsIGFwcGxpY2F0 aW9uDQo+ID4gPiB0aHJlYWRzIGludG8gb25lLg0KPiA+ID4gPHA+SSBhbSB1c2luZyBSSDgg TGludXggd2l0aCBnbGliYy0yLjMuMi00LjgwLCBrZXJuZWwgMi40LjE4LTI2LjguMHNtcCwN Cj4gPiA+IGNvbXBpbGluZyB3aXRoIGdjYyAyLjk1LjMgKGNhbid0IGdvIGhpZ2hlciBiZWNh dXNlIG9mIHNvdXJjZSBjb2RlDQo+ID4gPiBkZXBlbmRlbmNpZXMgaXNzdWVzKS4gSSBhbSBp bmNsdWRpbmcgc291cmNlIGNvZGUgZm9yIHRoZSBsaXR0bGUgdGVzdA0KPiA+ID4gcHJvZ3Jh bSBhbmQgYmFja3RyYWNlIGFmdGVyIGl0J3Mgc3R1Y2sgaW4gcmVjdigpIC0geW91IGNhbiBz ZWUgdGhhdA0KPiA+ID4gZXZlcnl0aGluZyBpcyBpbiBvbmUgdGhyZWFkLCBhbmQgZ2RiIGRv ZXMgbm90IHNob3cgYW55IG1vcmUgdGhyZWFkcw0KPiA+ID4gd2hhdHNvZXZlci4NCj4gPiA+ IDxwPlNvLCBpZiB5b3UgY291bGQgc29sdmUgdGhlIG15c3RlcnkgZm9yIG1lLCBpdCB3aWxs IGJlIG11Y2gNCj4gYXBwcmVjaWF0ZWQhDQo+ID4gPiBJIGNhbm5vdCB3YWl0IHRvIGdldCBt eSBoYW5kcyBvbiBhbGwgdGhlIGZlYXR1cmVzIHRoYXQgdGhlIG1hbnVhbCB0YWxrcw0KPiA+ ID4gYWJvdXQgLSBhbmQgZnJvbSBnZW5lcmFsIExpbnV4IGNvbW11bml0eSBidXp6IHlvdSBn dXlzIGFyZSBtdWNoIGJldHRlcg0KPiA+ID4gdGhlbiBSYXRpb25hbCBQdXJpZnkuDQo+ID4g PiA8cD5SZWdhcmRzLA0KPiA+ID4gPGJyPkFsZXgNCj4gPiA+IDxwPihnZGIpIGJ0DQo+ID4g PiA8YnI+IzAmbmJzcDsgMHg0MDBiYjI2MiBpbiB2Z1BsYWluX2RvX3N5c2NhbGwgKCkgZnJv bQ0KPiA+ID4gL2hvbWUvYWdpL2xpbnV4L2xpYi92YWxncmluZC92YWxncmluZC5zbyA8YnI+ IzEmbmJzcDsgMHg0MDBhOGMxZSBpbg0KPiA+ID4gdmdJbnRlcmNlcHRfcmVjdiAocz00LCBi dWY9MHg0MGU1M2IxMCwgbGVuPTEwMDAsIGZsYWdzPTApIGF0DQo+ID4gPiB2Z19pbnRlcmNl cHQuYzoxNTINCj4gPiA+IDxicj4jMiZuYnNwOyAweDQwMGE4YzM0IGluIHJlY3YgKHM9NCwg YnVmPTB4NDBlNTNiMTAsIGxlbj0xMDAwLCBmbGFncz0wKQ0KPiA+ID4gYXQgdmdfaW50ZXJj ZXB0LmM6MTU3DQo+ID4gPiA8YnI+IzMmbmJzcDsgMHgwODA0ODc5MCBpbiBMaXN0ZW5lclN0 YXJ0KHZvaWQqKSAocFBhcm09MHgwKSBhdA0KPiBtYWluLmNwcDo1OQ0KPiA+ID4gPGJyPiM0 Jm5ic3A7IDB4NDAxM2E1OGQgaW4gdGhyZWFkX3dyYXBwZXIgKGluZm89MHhmZmZmZmUwMCkg YXQNCj4gPiA+IHZnX2xpYnB0aHJlYWQuYzo2NzEgPGJyPiM1Jm5ic3A7IDB4NDAwOWFiODAg aW4NCj4gPiA+IGRvX19hcHBseV9pbl9uZXdfdGhyZWFkX2JvZ3VzUkEgKCkgYXQgdmdfc2No ZWR1bGVyLmM6MjE1NSA8YnI+IzYmbmJzcDsNCj4gPiA+IDB4MDgwNDg2OTUgaW4gbWFpbiAo KSBhdCBtYWluLmNwcDoyNQ0KPiA+ID4gPGJyPiM3Jm5ic3A7IDB4NDAxNzk0YWQgaW4gX19s aWJjX3N0YXJ0X21haW4gKCkgZnJvbSAvbGliL2xpYmMuc28uNg0KPiA+ID4gPHByZT4tLSZu YnNwOw0KPiA+ID4gQWxleCBHLg0KPiA+ID4NCj4gSXZlcnNoZW4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmDQo+ ID4NCj4gPm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5icw0KPiBwDQo+ID4gPjsmbmJzcDsmbmJzcDsm bmJzcDsgSW5ldCBUZWNobm9sb2dpZXMsIEluYy4gTmV0d29yayBQcm9kdWN0cw0KPiA+ID4N Cj4gRGVwdC4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzDQo+ID4gPnA7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDE1MDAgTi4NCj4gR3JlZW52aWxs ZQ0KPiA+ID4gQXZlLiBJbmV0IFRlY2hub2xvZ2llcw0KPiA+ID4NCj4gSW5jLiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwDQo+ID4gPjsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgUmljaGFyZHNvbiwgVFgNCj4gNzUwODENCj4gPiA+IFBob25l Og0KPiA+ID4NCj4gKzEtNDY5LTMzMC00Mjk1Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo+ID4gPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBV U0ENCj4gPiA+DQo+ID4gPiAiQmxhY2sgSG9sZXMgYXJlIHdoZXJlIEdvZCBkaXZpZGVkIGJ5 IHplcm8iPC9wcmU+DQo+ID4gPiAmbmJzcDs8L2h0bWw+DQo+ID4NCj4gPg0KPiA+DQo+ID4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiA+IFRoaXMgc2YubmV0IGVtYWlsIGlzIHNwb25zb3JlZCBieTpUaGlua0dlZWsNCj4g PiBXZWxjb21lIHRvIGdlZWsgaGVhdmVuLg0KPiA+IGh0dHA6Ly90aGlua2dlZWsuY29tL3Nm DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiBWYWxncmluZC11c2VycyBtYWlsaW5nIGxpc3QNCj4gPiBWYWxncmluZC11c2Vyc0Bs aXN0cy5zb3VyY2Vmb3JnZS5uZXQNCj4gPiBodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5l dC9saXN0cy9saXN0aW5mby92YWxncmluZC11c2Vycw0KPiA+DQo+DQo+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gVGhpcyBz Zi5uZXQgZW1haWwgaXMgc3BvbnNvcmVkIGJ5OlRoaW5rR2Vlaw0KPiBXZWxjb21lIHRvIGdl ZWsgaGVhdmVuLg0KPiBodHRwOi8vdGhpbmtnZWVrLmNvbS9zZg0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBWYWxncmluZC11c2VycyBt YWlsaW5nIGxpc3QNCj4gVmFsZ3JpbmQtdXNlcnNAbGlzdHMuc291cmNlZm9yZ2UubmV0DQo+ IGh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3ZhbGdyaW5k LXVzZXJzDQoNCi0tDQpBbGV4IEcuIEl2ZXJzaGVuICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEluZXQgVGVjaG5vbG9naWVzLCBJbmMuDQpOZXR3b3JrIFByb2R1Y3RzIERlcHQuICAg ICAgICAgICAgICAgICAgICAgIDE1MDAgTi4gR3JlZW52aWxsZSBBdmUuDQpJbmV0IFRlY2hu b2xvZ2llcyBJbmMuICAgICAgICAgICAgICAgICAgICAgIFJpY2hhcmRzb24sIFRYIDc1MDgx DQpQaG9uZTogKzEtNDY5LTMzMC00Mjk1ICAgICAgICAgICAgICAgICAgICAgIFVTQQ0KDQoi QmxhY2sgSG9sZXMgYXJlIHdoZXJlIEdvZCBkaXZpZGVkIGJ5IHplcm8iDQoNCg0K |
|
From: Sebastian K. <sk@z.pl> - 2003-04-24 22:30:22
|
Dnia czw 24. kwiecie=F1 2003 23:31, Alex Ivershen napisa=B3: > Sorry for off-topic, but I would like to ask Valgrind users a question = - > no=0D doubt some of you have run into this. I am deeply interested in f= inding > a performance profiler that works without code recompilation. Gprof is > great, but ... can't use it. Is there anything out there for Linux that > works like valgrind - on executalbles? Or at least on object files? I w= ould > truly appreciate any feedback. Have you tried cachegrind skin, or even KCachegrind + Calltree skin? This stuff (esp. Kcachegrind + Calltree skin) does quite nice profiling. = And=20 works on everything Valgrind works with, since it's Valgrind :) rgds Sebastian --=20 "Never undersetimate the power of human stupidity" -- from notebooks of L= =2EL. |
|
From: Robert W. <rj...@du...> - 2003-04-25 01:46:59
|
> Sorry for off-topic, but I would like to ask Valgrind users a question - = no > doubt some of you have run into this. I am deeply interested in finding a > performance profiler that works without code recompilation. Gprof is grea= t, but > ... can't use it. Is there anything out there for Linux that works like > valgrind - on executalbles? Or at least on object files? I would truly > appreciate any feedback. Not at all off-topic :-) There's a patch to Valgrind to do this. Take a look at Jeremy Fitzhardinge's vgprof stuff. I'm not so sure how up-to-date it is with respect to the current CVS head, but it worked pretty well for me last time I tried it out. http://www.goop.org/~jeremy/valgrind/ This produces a gmon.out file that can be parsed by an updated version of gprof (which Jeremy also provides.) Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X