Menu
▾
▴
valgrind-users — General discussion list for Valgrind users
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(12) |
Oct
(16) |
Nov
(1) |
Dec
|
| 2024 |
Jan
(4) |
Feb
(3) |
Mar
(6) |
Apr
(17) |
May
(2) |
Jun
(33) |
Jul
(13) |
Aug
(1) |
Sep
(6) |
Oct
(8) |
Nov
(6) |
Dec
(15) |
| 2025 |
Jan
(5) |
Feb
(11) |
Mar
(8) |
Apr
(20) |
May
(1) |
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Lee, H. <HJ...@ec...> - 2003-04-26 00:03:31
|
Hi,
If I use string type for example ---> string a("Hello, world"), the memory
allocated for string isn't freed when program exit.
valgrand reported it is not-freed block. Here is valgrind reports logs.
Why is it not freed when program exits? I am using RH6.2.
----------------
==2264== Addrcheck, a fine-grained address checker for x86-linux.
==2264== Copyright (C) 2002, and GNU GPL'd, by Julian Seward.
==2264== Using valgrind-1.9.5, a program instrumentation system for
x86-linux.
==2264== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==2264==
==2264== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==2264== malloc/free: in use at exit: 1280 bytes in 1 blocks.
==2264== malloc/free: 1 allocs, 0 frees, 1280 bytes allocated.
==2264== For counts of detected errors, rerun with: -v
==2264== searching for pointers to 1 not-freed blocks.
==2264== checked 3490188 bytes.
==2264==
==2264== 1280 bytes in 1 blocks are still reachable in loss record 1 of 1
==2264== at 0x4014D4C8: malloc (in /usr/local/lib/valgrind/valgrind.so)
==2264== by 0x4021B96F: __default_alloc_template<true,
0>::chunk_alloc(unsigned int, int &) (in
/usr/lib/libstdc++-2-libc6.1-1-2.9.0.so)
==2264== by 0x4021BA28: __default_alloc_template<true,
0>::refill(unsigned int) (in /usr/lib/libstdc++-2-libc6.1-1-2.9.0.so)
==2264== by 0x402140F2: basic_string<char, string_char_traits<char>,
__default_alloc_template<true, 0> >::replace(unsigned int, unsigned int,
char const *, unsigned int) (in /usr/lib/libstdc++-2-libc6.1-1-2.9.0.so)
==2264== by 0x402169B7: basic_string<char, string_char_traits<char>,
__default_alloc_template<true, 0> >::basic_string(char const *) (in
/usr/lib/libstdc++-2-libc6.1-1-2.9.0.so)
==2264== by 0x804A1D4: main (str_test.cpp:19)
==2264== by 0x402729CA: __libc_start_main (in /lib/libc-2.1.3.so)
==2264== by 0x804A130: ??? (/usr/include/g++-2/stl_alloc.h:533)
==2264==
==2264== LEAK SUMMARY:
==2264== definitely lost: 0 bytes in 0 blocks.
==2264== possibly lost: 0 bytes in 0 blocks.
==2264== still reachable: 1280 bytes in 1 blocks.
==2264== suppressed: 0 bytes in 0 blocks.
------------------
HJ
|
|
From: Vimal R. <vim...@ya...> - 2003-04-25 23:10:01
|
Hi,
I am getting an Abort signal when I run valgrind on GNU smalltalk. The problem
(I think) seems to be with the signal handlers. GNU Smalltalk sets its own
signal handlers. After reading the documentation (2.13.5 Signals), I feel the
problem is occurring after valgrind catches the signal, but the return back to
the client code's handler bombs.
Here is the output of valgrind :
/vimal/gst-linux-x86> valgrind --trace-signals=yes --error-limit=no
./gst ../smalltalk-2.1/tests/sets.st
See attached file : gst_output
I have included the program output separately at the end.
The combined output (if it helps to better see the sequence of events):
See attached file: combined_output
Here is the client signal hanlder code (just included the important functions)
:
See attached file : gst_signal_handler_code
Here is a look at the dynamic dependencies of gst:
/vimal/gst-linux-x86> ldd ./gst
libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
libdl.so.2 => /lib/libdl.so.2 (0x4002d000)
libreadline.so.4 => /usr/lib/libreadline.so.4 (0x40030000)
libtermcap.so.2 => /lib/libtermcap.so.2 (0x40056000)
libgmp.so.3 => /usr/lib/libgmp.so.3 (0x4005a000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40082000)
libm.so.6 => /lib/i686/libm.so.6 (0x40097000)
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x400ba000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Another important thing to note is this happens only when the garbage collector
is invoked (I placed a command in the smalltalk file sets.st which forces
garbage collection). If I run the same file (sets.st) without invoking garbage
collection (GC) it runs perfectly. When the GC is invoked, there is surely some
particular signal thrown around (there is some new memory allocated, cleaned up
etc in the heap ) and I guess that is the one to look out for. I'm sorry, i'm
not in a position to pin point the problem as I'm just a user of GNU Smalltalk.
If you want to reproduce the problem, GNU Smalltalk-2.1 is there for download
here : http://www.gnu.org/software/smalltalk/ Or I can send you the copy I'm
using.
Please let me know if you need any more diagnostic information.
Thanks,
Vimal
=====
Vimal Reddy
Graduate Student, ECE
North Carolina State University
Raleigh, NC
Ph: (919) 836-8254 Web: http://www4.ncsu.edu/~vkreddy
__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com |
|
From: Nicholas N. <nj...@ca...> - 2003-04-25 10:14:49
|
On Thu, 24 Apr 2003, Julian Seward wrote: > Writing a skin to do this should be very easy. I suggest you > start with the lackey skin. Or maybe the cacheprof one. > You can instrument the basic blocks in flexible ways as they > are passed to your skin. One simple thing to do is to call > function(s) of your choice when LOADs / STOREs, and their > FPU equivalents, happen. ( s/cacheprof/cachegrind ) Read the docs on how to write a skin; there should be a link to it from within the main docs, coregrind/docs/coregrind_skins.html if not. include/vg_skin.h contains all the declarations relevant for writing skins, it's worth reading to see what services Valgrind provides to make skin-writing easier. And yes, it should be about as easy as any skin to write. N |
|
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... |
|
From: Julian S. <js...@ac...> - 2003-04-24 23:28:17
|
Known problem .. under consideration. See Q10 of http://developer.kde.org/~sewardj/docs-1.9.5/FAQ.txt J On Thursday 24 April 2003 11:34 pm, Sergio Ito wrote: > Hi all, > > first I'd like to say that valgrind is one of most > amazing tools I already used. Thanks for making it > such a great tool. > > I got some problems when my system was upgraded to red > hat 8.0 and we migrated to gcc 3.2.2 + valgrind-1.9.5. > I have a multithread app and it hangs somewhere > calling oldselect... strace gave this: > > fcntl(13, F_GETFL) = 0x801 (flags > O_WRONLY|O_NONBLOCK) > write(13, "MTclChannel FOPEN_MAX=16\nMTclCha"..., 57) > = 57 > fcntl(13, F_GETFL) = 0x801 (flags > O_WRONLY|O_NONBLOCK) > fcntl(13, F_SETFL, O_WRONLY) = 0 > oldselect(19, [17 18], NULL, NULL, NULL > > > and, pstack generated this: > > 0x4018ccde: vgPlain_post_known_blocking_syscall + > 0x20f (12, 4528d4c0, 0, 0, 0) > 0x40176563: __select + 0x2d (12, 4528d4c0, 0, 0, 0, 0) > + 1030 > 0x09b6a02f: _ZN11MTclChannel18shellCmdEventLoop_Ev + > 0x12f (4528afa8, 9b69ee0) > 0x09b69ef1: _ZN11MTclChannel21runShellCmdEventLoop_EPv > + 0x11 (4528afa8, 0, 0, 0, 0, 0) + 18 > 0x4026b822: thread_wrapper + 0xad (4528b040, 0, 0, 0, > 0, 0) + 789cc224 > 0x4016583e: do__apply_in_new_thread_bogusRA (4528afd0, > bfffc240, b0b0c60, 45287808, 452877d4, 45287798) + 40 > 0x09b69d23: > _ZN11MTclChannel4initEP10Tcl_InterpRN4_STL13basic_ostreamIcNS2_11char_trait >sIcEEEES7_ + 0x1c3 (b0b0c20, b0b0c60, b0b0c60, 4527c31c, > 45269e44, 1) + 10 > > valgrind-1.0.4 on red hat 7.2 was working properly. > > Any ideas?? > > Sergio > > > > > __________________________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo > http://search.yahoo.com > > > ------------------------------------------------------- > 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: Sergio I. <ser...@ya...> - 2003-04-24 22:34:17
|
Hi all, first I'd like to say that valgrind is one of most amazing tools I already used. Thanks for making it such a great tool. I got some problems when my system was upgraded to red hat 8.0 and we migrated to gcc 3.2.2 + valgrind-1.9.5. I have a multithread app and it hangs somewhere calling oldselect... strace gave this: fcntl(13, F_GETFL) = 0x801 (flags O_WRONLY|O_NONBLOCK) write(13, "MTclChannel FOPEN_MAX=16\nMTclCha"..., 57) = 57 fcntl(13, F_GETFL) = 0x801 (flags O_WRONLY|O_NONBLOCK) fcntl(13, F_SETFL, O_WRONLY) = 0 oldselect(19, [17 18], NULL, NULL, NULL and, pstack generated this: 0x4018ccde: vgPlain_post_known_blocking_syscall + 0x20f (12, 4528d4c0, 0, 0, 0) 0x40176563: __select + 0x2d (12, 4528d4c0, 0, 0, 0, 0) + 1030 0x09b6a02f: _ZN11MTclChannel18shellCmdEventLoop_Ev + 0x12f (4528afa8, 9b69ee0) 0x09b69ef1: _ZN11MTclChannel21runShellCmdEventLoop_EPv + 0x11 (4528afa8, 0, 0, 0, 0, 0) + 18 0x4026b822: thread_wrapper + 0xad (4528b040, 0, 0, 0, 0, 0) + 789cc224 0x4016583e: do__apply_in_new_thread_bogusRA (4528afd0, bfffc240, b0b0c60, 45287808, 452877d4, 45287798) + 40 0x09b69d23: _ZN11MTclChannel4initEP10Tcl_InterpRN4_STL13basic_ostreamIcNS2_11char_traitsIcEEEES7_ + 0x1c3 (b0b0c20, b0b0c60, b0b0c60, 4527c31c, 45269e44, 1) + 10 valgrind-1.0.4 on red hat 7.2 was working properly. Any ideas?? Sergio __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com |
|
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: Julian S. <js...@ac...> - 2003-04-24 22:29:39
|
Writing a skin to do this should be very easy. I suggest you start with the lackey skin. Or maybe the cacheprof one. You can instrument the basic blocks in flexible ways as they are passed to your skin. One simple thing to do is to call function(s) of your choice when LOADs / STOREs, and their FPU equivalents, happen. All in all a brilliant piece of engineering from Nick N. J On Thursday 24 April 2003 11:04 pm, Vimal Reddy wrote: > Hello list, > I'm a newbie to valgrind and want to find out if I can use Valgrind in my > project. I'm trying to get address traces for executables. Since valgrind > anyway checks each read and write, I was thinking it should be possible to > log the address referenced by the read/write. > > I'm pretty sure the cachegrind skin uses this (addresses) to simulate > different cache hierarchies. Or am I getting this wrong? Please let me > know if you think this is a feasible task, so I will then go ahead and do > some hacking to get the traces. > > cheers, > Vimal > > ===== > Vimal Reddy > Graduate Student, ECE > North Carolina State University > Raleigh, NC > Ph: (919) 836-8254 Web: http://www4.ncsu.edu/~vkreddy > > __________________________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo > http://search.yahoo.com > > > ------------------------------------------------------- > 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: Vimal R. <vim...@ya...> - 2003-04-24 22:04:41
|
Hello list, I'm a newbie to valgrind and want to find out if I can use Valgrind in my project. I'm trying to get address traces for executables. Since valgrind anyway checks each read and write, I was thinking it should be possible to log the address referenced by the read/write. I'm pretty sure the cachegrind skin uses this (addresses) to simulate different cache hierarchies. Or am I getting this wrong? Please let me know if you think this is a feasible task, so I will then go ahead and do some hacking to get the traces. cheers, Vimal ===== Vimal Reddy Graduate Student, ECE North Carolina State University Raleigh, NC Ph: (919) 836-8254 Web: http://www4.ncsu.edu/~vkreddy __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com |
|
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: Jeff S. <je...@tv...> - 2003-04-24 21:04:04
|
On Thu, 24 Apr 2003, Nicholas Nethercote wrote: > On Thu, 24 Apr 2003, Jeff Sadowski wrote: > > > valgrind 1.9.5 > > and kernel 2.5.68 > > Is there anything spceicial I need to do in order to get it to work? > > Try this patch, courtesy of Anders Gustafsson on Monday :) > Thanks that worked :) > N > > |
|
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: 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: Alex I. <ale...@in...> - 2003-04-24 19:54:26
|
<!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: Nicholas N. <nj...@ca...> - 2003-04-24 18:56:03
|
On Thu, 24 Apr 2003, Jeff Sadowski wrote: > valgrind 1.9.5 > and kernel 2.5.68 > Is there anything spceicial I need to do in order to get it to work? Try this patch, courtesy of Anders Gustafsson on Monday :) N |
|
From: Jeff S. <je...@tv...> - 2003-04-24 18:45:24
|
On Thu, 24 Apr 2003, Julian Seward wrote: > > What version of V and what version of the kernel? v-1.9.5 works > with at least some 2.5.Xs. > > J > valgrind 1.9.5 and kernel 2.5.68 Is there anything spceicial I need to do in order to get it to work? > > On Thursday 24 April 2003 7:21 pm, Jeff Sadowski wrote: > > I recently tried out the 2.5.x kernel > > when I try to run valgrind I get the following error message > > > > valgrind.so: When searching for client's argc/argc/envp: > > ELF frame does not look like 2.2.X or 2.4.X. > > See kernel sources linux/fs/binfmt_elf.c to make sense of this. > > valgrind.so: Startup or configuration error: > > couldn't find client's argc/argc/envp > > valgrind.so: Unable to start up properly. Giving up. > > > > I even recompiled valgrind with no problems and I get > > the same error message. > > > > > > > > ------------------------------------------------------- > > 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: Julian S. <js...@ac...> - 2003-04-24 18:29:28
|
What version of V and what version of the kernel? v-1.9.5 works with at least some 2.5.Xs. J On Thursday 24 April 2003 7:21 pm, Jeff Sadowski wrote: > I recently tried out the 2.5.x kernel > when I try to run valgrind I get the following error message > > valgrind.so: When searching for client's argc/argc/envp: > ELF frame does not look like 2.2.X or 2.4.X. > See kernel sources linux/fs/binfmt_elf.c to make sense of this. > valgrind.so: Startup or configuration error: > couldn't find client's argc/argc/envp > valgrind.so: Unable to start up properly. Giving up. > > I even recompiled valgrind with no problems and I get > the same error message. > > > > ------------------------------------------------------- > 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: Jeff S. <je...@tv...> - 2003-04-24 18:21:38
|
I recently tried out the 2.5.x kernel
when I try to run valgrind I get the following error message
valgrind.so: When searching for client's argc/argc/envp:
ELF frame does not look like 2.2.X or 2.4.X.
See kernel sources linux/fs/binfmt_elf.c to make sense of this.
valgrind.so: Startup or configuration error:
couldn't find client's argc/argc/envp
valgrind.so: Unable to start up properly. Giving up.
I even recompiled valgrind with no problems and I get
the same error message.
|
|
From: Jos v. d. O. <jos...@wu...> - 2003-04-23 09:49:17
|
Thanks Mathieu, Melchior and Melchior, I've succesfully found the memory leak by using the software mesa library instead of the nvidida driver. Best regards, Jos Melchior FRANZ wrote: > * Mathieu Malaterre -- Thursday 17 April 2003 16:03: > >>If you are using the lastest nvidia driver you can use: >> >>$__GL_FORCE_GENERIC_CPU=1 valgrind ... > > > Or else you can still override the nvidia driver by mesa, as in > > $ LD_PRELOAD=/usr/lib/GL/libGL.so.1.3.mesasoft valgrind ... > > m. > > > ------------------------------------------------------- > 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: Todd R. <ric...@pr...> - 2003-04-23 08:38:33
|
I finally rebuilt a machine(Dell Pentium Xenon) with vanilla Redhat 8.0 and
the pthread poll() problem disapeared so it must be some issue with the
later glibc. However, this system claims an incorrect 1 4byte read and 1 4
byte write error in select() (seemingly valid code) when validating a perl
program that does not occur on newer systems...
Todd
----- Original Message -----
From: "Sefer Tov" <se...@ho...>
To: <val...@li...>
Sent: Saturday, April 19, 2003 11:45 PM
Subject: [Valgrind-users] Re: valgrind / pthreads issue
> Hi!
>
> Oddly enough, I've been experiencing the same problem.
> I'm using Linux Mandrake 9.1, which appears to come with a version of
glibc
> 2.3.2 (but I think this was happening with older glibc's as well).
>
> I've written a tiny skeleton server that pre-creates a few threads
> (successfully) and then enters a poll loop (from which point the threads
are
> not getting any cpu time at all).
>
> It seems that there is some pthreads/poll issue, but this may also be
> related that I'm running everything on a laptop and we have already
noticed
> that there might be some scheduling problems because TSC register being
used
> is variable-rate on machines with power management active.
>
> Thanks,
> Sefer.
>
>
> >That's very strange. V has threading problems with glibcs > 2.3.1,
> >though. So I wonder if that's it. Do you have an older linux
> >distro you can try it on, something like RH 7.3, or Suse 8.1 ?
> >Basically anything with glibc 2.3.1 or before; 2.2.5 would be
> >even better.
>
> >J
>
> _________________________________________________________________
> Add photos to your messages with MSN 8. Get 2 months FREE*.
> http://join.msn.com/?page=features/featuredemail
>
>
>
> -------------------------------------------------------
> 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: 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: John L. <le...@mo...> - 2003-04-23 00:03:59
|
On Wed, Apr 23, 2003 at 12:30:29AM +0100, Julian Seward wrote:
> It will show what shared objects my_program relies on, or say:
>
> not a dynamic executable
>
> it my_program is statically linked.
Typo, should be:
if my_program...
regards
john
|
|
From: Julian S. <js...@ac...> - 2003-04-22 23:30:40
|
Greetings. We've majorly expanded the FAQ to include workarounds for more
or less all failure conditions for which we know a workaround. This includes
a large fraction of the failures people seem to encounter in practice, so
if you've been having problems with V it might be worth taking a look.
The FAQ is below, and we'll included it in all future distributions.
I'll also put it up on the web site.
J
A mini-FAQ for valgrind, version 1.9.6
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Last revised 22 Apr 2003
~~~~~~~~~~~~~~~~~~~~~~~~
-----------------------------------------------------------------
Q1. Programs run OK on valgrind, but at exit produce a bunch
of errors a bit like this
==20755== Invalid read of size 4
==20755== at 0x40281C8A: _nl_unload_locale (loadlocale.c:238)
==20755== by 0x4028179D: free_mem (findlocale.c:257)
==20755== by 0x402E0962: __libc_freeres (set-freeres.c:34)
==20755== by 0x40048DCC: vgPlain___libc_freeres_wrapper
(vg_clientfuncs.c:585)
==20755== Address 0x40CC304C is 8 bytes inside a block of size 380
free'd
==20755== at 0x400484C9: free (vg_clientfuncs.c:180)
==20755== by 0x40281CBA: _nl_unload_locale (loadlocale.c:246)
==20755== by 0x40281218: free_mem (setlocale.c:461)
==20755== by 0x402E0962: __libc_freeres (set-freeres.c:34)
and then die with a segmentation fault.
A1. When the program exits, valgrind runs the procedure
__libc_freeres() in glibc. This is a hook for memory debuggers,
so they can ask glibc to free up any memory it has used. Doing
that is needed to ensure that valgrind doesn't incorrectly
report space leaks in glibc.
Problem is that running __libc_freeres() in older glibc versions
causes this crash.
WORKAROUND FOR 1.1.X and later versions of valgrind: use the
--run-libc-freeres=no flag. You may then get space leak
reports for glibc-allocations (please _don't_ report these
to the glibc people, since they are not real leaks), but at
least the program runs.
-----------------------------------------------------------------
Q2. My program dies complaining that syscall 197 is unimplemented.
A2. 197, which is fstat64, is supported by valgrind. The problem is
that the /usr/include/asm/unistd.h on the machine on which your
valgrind was built, doesn't match your kernel -- or, to be more
specific, glibc is asking your kernel to do a syscall which is
not listed in /usr/include/asm/unistd.h.
The fix is simple. Somewhere near the top of
coregrind/vg_syscalls.c, add the following line:
#define __NR_fstat64 197
Rebuild and try again. The above line should appear before any
uses of the __NR_fstat64 symbol in that file. If you look at the
place where __NR_fstat64 is used in vg_syscalls.c, it will be
obvious why this fix works.
-----------------------------------------------------------------
Q3. My (buggy) program dies like this:
valgrind: vg_malloc2.c:442 (bszW_to_pszW):
Assertion `pszW >= 0' failed.
And/or my (buggy) program runs OK on valgrind, but dies like
this on cachegrind.
A3. If valgrind shows any invalid reads, invalid writes and invalid
frees in your program, the above may happen. Reason is that your
program may trash valgrind's low-level memory manager, which then
dies with the above assertion, or something like this. The cure
is to fix your program so that it doesn't do any illegal memory
accesses. The above failure will hopefully go away after that.
-----------------------------------------------------------------
Q4. I'm running Red Hat Advanced Server. Valgrind always segfaults at
startup.
A4. Known issue with RHAS 2.1, due to funny stack permissions at
startup. However, valgrind-1.9.4 and later automatically handle
this correctly, and should not segfault.
-----------------------------------------------------------------
Q5. I try running "valgrind my_program", but my_program runs normally,
and Valgrind doesn't emit any output at all.
A5. Is my_program statically linked? Valgrind doesn't work with
statically linked binaries. It must rely on at least one shared
object. To detrmine if a my_program is statically linked, run:
ldd my_program
It will show what shared objects my_program relies on, or say:
not a dynamic executable
it my_program is statically linked.
-----------------------------------------------------------------
Q6. I try running "valgrind my_program" and get Valgrind's startup message,
but I don't get any errors and I know my program has errors.
A6. By default, Valgrind only traces the top-level process. So if your
program spawns children, they won't be traced by Valgrind by default.
Also, if your program is started by a shell script, Perl script, or
something similar, Valgrind will trace the shell, or the Perl
interpreter, or equivalent.
To trace child processes, use the --trace-children=yes option.
If you are tracing large trees of processes, it can be less
disruptive to have the output sent over the network. Give
valgrind the flag --logsocket=127.0.0.1:12345 (if you want
logging output sent to port 12345 on localhost). You can
use the valgrind-listener program to listen on that port:
valgrind-listener 12345
Obviously you have to start the listener process first.
See the documentation for more details.
-----------------------------------------------------------------
Q7. My threaded server process runs unbelievably slowly on
valgrind. So slowly, in fact, that at first I thought it
had completely locked up.
A7. We are not completely sure about this, but one possibility
is that laptops with power management fool valgrind's
timekeeping mechanism, which is (somewhat in error) based
on the x86 RDTSC instruction. A "fix" which is claimed to
work is to run some other cpu-intensive process at the same
time, so that the laptop's power-management clock-slowing
does not kick in. We would be interested in hearing more
feedback on this.
-----------------------------------------------------------------
Q8. My program dies (exactly) like this:
REPE then 0xF
valgrind: the `impossible' happened:
Unhandled REPE case
A8. Yeah ... that I believe is a P4 specific instruction. Are you
building your app with -march=pentium4 or something like that?
Others have reported that removing the flag works around this.
In fact this is pretty easy to fix and I do have it on my
to-do-for-1.9.6 list.
I'd be interested to hear if you can get rid of it by changing
your application build flags.
-----------------------------------------------------------------
Q9. My program dies complaining that __libc_current_sigrtmin
is unimplemented.
A9. Try the following. It is an experiment, but it might work.
We would very much appreciate you telling us if it does/
does not work for you.
In vg_libpthread.c, add the 3 functions below.
In vg_libpthread_unimp.c, remove the stubs for the same 3
functions.
Let me know if it helps. Quite a lot of other valgrind users
complain about this, but I have never been able to reproduce it,
so fixing it isn't easy. So it's useful if you can try.
int __libc_current_sigrtmin (void)
{
return -1;
}
int __libc_current_sigrtmax (void)
{
return -1;
}
int __libc_allocate_rtsig (int high)
{
return -1;
}
-----------------------------------------------------------------
Q10. I upgraded to Red Hat 9 and threaded programs now act
strange / deadlock when they didn't before.
A10. Thread support on glibc 2.3.2+ with NPTL is not as
good as on older LinuxThreads-based systems. We have
this under consideration. Avoid Red Hat >= 8.1 for
the time being, if you can.
-----------------------------------------------------------------
Q11. I really need to use the NVidia libGL.so in my app.
Help!
A11. NVidia also noticed this it seems, and the "latest" drivers
(version 4349, apparently) come with this text
DISABLING CPU SPECIFIC FEATURES
Setting the environment variable __GL_FORCE_GENERIC_CPU to a
non-zero value will inhibit the use of CPU specific features
such as MMX, SSE, or 3DNOW!. Use of this option may result in
performance loss. This option may be useful in conjunction with
software such as the Valgrind memory debugger.
Set __GL_FORCE_GENERIC_CPU=1 and Valgrind should work. This has
been confirmed by various people. Thanks NVidia!
-----------------------------------------------------------------
Q12. My program dies like this (often at exit):
VG_(mash_LD_PRELOAD_and_LD_LIBRARY_PATH): internal error:
(loads of text)
A12. We're not entirely sure about this, and would appreciate
someone sending a simple test case for us to look at.
One possible cause is that your program modifies its
environment variables, possibly including zeroing them
all. Avoid this if you can.
In any case, you may be able to work around it like this:
Comment out the
call to VG_(core_panic) at coregrind/vg_main.c:1647 and see
if that helps. The text of coregrind/vg_main.c:1647 is as follows:
VG_(core_panic)("VG_(mash_LD_PRELOAD_and_LD_LIBRARY_PATH) failed\n");
and so it's this call you want to comment out.
-----------------------------------------------------------------
Q13. My program dies like this:
error: /lib/librt.so.1: symbol __pthread_clock_settime, version
GLIBC_PRIVATE not defined in file libpthread.so.0 with link time
reference
A13. This is a total swamp. Nevertheless there is a way out.
It's a problem which is not easy to fix. Really the problem is
that /lib/librt.so.1 refers to some symbols
__pthread_clock_settime and __pthread_clock_gettime in
/lib/libpthread.so which are not intended to be exported, ie
they are private.
Best solution is to ensure your program does not use
/lib/librt.so.1.
However .. since you're probably not using it directly, or even
knowingly, that's hard to do. You might instead be able to fix
it by playing around with coregrind/vg_libpthread.vs. Things to
try:
Remove this
GLIBC_PRIVATE {
__pthread_clock_gettime;
__pthread_clock_settime;
};
or maybe remove this
GLIBC_2.2.3 {
__pthread_clock_gettime;
__pthread_clock_settime;
} GLIBC_2.2;
or maybe add this
GLIBC_2.2.4 {
__pthread_clock_gettime;
__pthread_clock_settime;
} GLIBC_2.2;
GLIBC_2.2.5 {
__pthread_clock_gettime;
__pthread_clock_settime;
} GLIBC_2.2;
or some combination of the above. After each change you need to
delete coregrind/libpthread.so and do make && make install.
I just don't know if any of the above will work. If you can
find a solution which works, I would be interested to hear it.
To which someone replied:
I deleted this:
GLIBC_2.2.3 {
__pthread_clock_gettime;
__pthread_clock_settime;
} GLIBC_2.2;
and it worked.
-----------------------------------------------------------------
(this is the end of the FAQ.)
|
|
From: Nicholas N. <nj...@ca...> - 2003-04-22 21:48:30
|
On Tue, 22 Apr 2003, Greg Hosler wrote: > The raw valgring.spec file in valgrind-1.9.5.tar.bz2 contains an error. In the > files section it neglects to mention the following files. > > /usr/bin/valgrind-listener > /usr/bin/vg_regtest > > these need to be added, otherwise rpm on RH9 will complain that these files are > in the payload area, but not saved to the rpm. I just fixed it in the HEAD, thanks. N |
|
From: Madhu M. K. <mm...@ya...> - 2003-04-22 16:48:37
|
Nicholas Nethercote wrote: >On Tue, 22 Apr 2003, Joerg Beyer wrote: > >> I have a complicated setup where valgrind is not finding errors. >> In my setup I have a apache 1.3 with a c++ module, so it >> is mixed C/C++ code. Even at the very first call to initialize >> valgrind is not detecting a new[100]/delete (not delete [] !) >> pair of calls as error. >> >> Apache introduces some difficulties for valgrind: >> - it is mixed C/C++ code >> - all kinds of signal are catched by a signal handler >> - all kinds of libraries are linked to the module, like xalan, xerces >> - it is a large application with a memory footprint of ~ 20 MB. AFAIK, Apache also does it's own mem pooling, which is why I suspect the error is not showing up. Cheerio, M Madhu M Kurup /* Nemo Me Impune Lacessit */ mmk at yahoo-inc dt com |
188 messages has been excluded from this view by a project administrator.
