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
(9) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: Biswapesh C. <bis...@tc...> - 2003-04-07 04:22:43
|
IIRC, the wine folks have a reasonable configure time check for NPTL in CVS, so maybe you can simply swipe their code ? Of course, the issue they are facing is that what if the program (wine/valgrind) is compiled with one kind of threading support and the binary shipped to a system with a different type of threading ? Basically, in that case, you need a runtime check as well. > On Sunday 06 April 2003 6:48 pm, Robert Walsh wrote: > > > Anyone have a reliable check easily to hand? > > > > Yeugh. I don't know if this is reliable, but pthread_tryjoin_np is > > implemented in nptl but not in the original pthread stuff. Perhaps a > > check for that will let you know? It will certainly let you know if > > pthread_tryjoin_np is implemented, but you might allow yourself to infer > > from that that it's nptl... :-) > > Hmm. Sounds a plausible scheme, but ... > > On the one hand (on RH 9), nm /lib/tls/libpthread.so.0 | grep tryjoin > shows pthread_tryjoin_np as an exported text symbol ("T"). > > On the other hand, you can't link against it: > > sewardj@localhost:~/VgHEAD/valgrind$ cat nptltest.c > > #include <pthread.h> > extern int pthread_tryjoin_np; > int main (int argc, char * argv ) > { > int* p = (int*)(& pthread_tryjoin_np); > return 0; > } > > sewardj@localhost:~/VgHEAD/valgrind$ gcc -o nptltest nptltest.c > -lpthread > /tmp/ccWjnvw9.o(.text+0x13): In function `main': > : undefined reference to `pthread_tryjoin_np' > collect2: ld returned 1 exit status > > Now what? If the symbol is in the DSO, why can't I link to it? > Mystified. > > J > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users -- Biswa. |
From: Ranko Z. <ra...@sp...> - 2003-04-07 01:40:14
|
Hi All, First of all I would like to thank Julian for making this tool available. It is great! I'm addressing you because I'm experiencing something that for last two days drove me completely bannanas. I was checking one of my multithreaded app. against the Valgrind, found few mistakes and cleaned some of them up - but some of them I simply cannot understand how do they happen. And I was hoping that some of you might have expirienced the same - and found the solution. Basically, when I'm writing to a file via either write or pwrite I can see in gdb that I'm passing the correct pointers, but when libc performs a syscall, the buffer pointer gets somehow shifted for one byte inside the allocated buffer and crossing the allocated space thus having Valgrind complain about it. The behavior is not consistent because at some places pwrite works like a charm and at certain places it does this funny stuff. The error Valgrind gives is "Address 0x412C72B9 is 1 bytes inside a block of size 32 alloc'd" and the address offset is exactly 1 bytes from what I have passed to the pwrite according to gdb (0x412C72B8). I also see that Valgrind passes the same correct pointer to the library (at vg_libpthread.c:2142). The same error is being reported by both 1.0.4 and 1.9.4. What could be the cause of this behavior? Btw, application seems to be working fine without the Valgrind because the resulting files are correct in the format and the content (they are not missing the first byte or something), but then again, I'm afraid that I might be corrupting something someplace that could fire back afterwards. I've also tried to reproduce the problem in a smaller program, but unfortunately with no luck there. Thanks in advance, Ranko -- Ranko Zivojnovic, NOC Manager ra...@sp... Network Operations Center Spidernet Services Ltd., Tel: +357 22 844844 Nicosia, Cyprus FAX: +357 22 669470 |
From: Julian S. <js...@ac...> - 2003-04-06 23:37:25
|
On Sunday 06 April 2003 6:48 pm, Robert Walsh wrote: > > Anyone have a reliable check easily to hand? > > Yeugh. I don't know if this is reliable, but pthread_tryjoin_np is > implemented in nptl but not in the original pthread stuff. Perhaps a > check for that will let you know? It will certainly let you know if > pthread_tryjoin_np is implemented, but you might allow yourself to infer > from that that it's nptl... :-) Hmm. Sounds a plausible scheme, but ... On the one hand (on RH 9), nm /lib/tls/libpthread.so.0 | grep tryjoin shows pthread_tryjoin_np as an exported text symbol ("T"). On the other hand, you can't link against it: sewardj@localhost:~/VgHEAD/valgrind$ cat nptltest.c #include <pthread.h> extern int pthread_tryjoin_np; int main (int argc, char * argv ) { int* p = (int*)(& pthread_tryjoin_np); return 0; } sewardj@localhost:~/VgHEAD/valgrind$ gcc -o nptltest nptltest.c -lpthread /tmp/ccWjnvw9.o(.text+0x13): In function `main': : undefined reference to `pthread_tryjoin_np' collect2: ld returned 1 exit status Now what? If the symbol is in the DSO, why can't I link to it? Mystified. J |
From: Julian S. <js...@ac...> - 2003-04-06 21:25:06
|
Ok, I've got the same problem running OpenOffice on R H 9, using the LD_ASSUME_KERNEL thing and auxinfo patch from Graydon. OO is blocking in accept(). We get to accept() at vg_intercept.c:140 (correct), which then calls VGL_(accept) (correct). Unfortunately this leads to the one in the same file rather than the one in vg_libpthread.c. Enquiring with LD_DEBUG=files confirms that ld.so has somehow done this, despite both valgrind.so and vg_libpthread.so being in the image. Graydon, Jeff, is there any known issue in glibc-2.3.2 to do with weak symbols not being overriden by non-weak symbols? What we've got here is just such a case. Mystified. J On Thursday 03 April 2003 6:56 am, da...@2g... wrote: > Quoting Jeremy Fitzhardinge <je...@go...>: > > On Wed, 2003-04-02 at 10:28, David Eriksson wrote: > > > Strace stops in poll, and if I attach to the server process with gdb I > > > get this stacktrace: > > > > > > (gdb) bt > > > #0 0x40183272 in vgPlain_do_syscall () from > > > /usr/local/lib/valgrind/valgrind.so > > > #1 0x4023c4d0 in __JCR_LIST__ () from /usr/lib/libglib-1.2.so.0 > > > #2 0x40170c97 in poll (__fds=0x4223bf3c, __nfds=0x2, __timeout=0xea60) > > > at vg_intercept.c:194 > > > #3 0x4022a3cb in g_main_poll () from /usr/lib/libglib-1.2.so.0 > > > #4 0x40229c95 in g_main_iterate () from /usr/lib/libglib-1.2.so.0 > > > #5 0x4022a0f4 in g_main_run () from /usr/lib/libglib-1.2.so.0 > > > #6 0x0804c671 in main (argc=0x0, argv=0xbfffe8e4) at smaccd.c:616 > > > #7 0x403d3907 in __libc_start_main () from /lib/libc.so.6 > > > > Hm, looks like the vg_intercept stuff isn't working - it's catching > > poll, but it isn't passing it into the threads library properly. What > > does ldd <your program> say? What is in /proc/<pid>/maps when you run > > it? What does the link command line look like? > > ldd says this: > > libgthread-1.2.so.0 => /usr/lib/libgthread-1.2.so.0 (0x4002a000) > libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x4002e000) > libpthread.so.0 => /lib/libpthread.so.0 (0x40054000) > libldap_r.so.2 => /usr/lib/libldap_r.so.2 (0x400a6000) > liblber.so.2 => /usr/lib/liblber.so.2 (0x400d4000) > libradiusclient.so.0 => > /usr/local/radiusclient/lib/libradiusclient.so.0 (0x400df000) > libssl.so.2 => /lib/libssl.so.2 (0x400e8000) > libcrypto.so.2 => /lib/libcrypto.so.2 (0x40119000) > libresolv.so.2 => /lib/libresolv.so.2 (0x401ed000) > libc.so.6 => /lib/libc.so.6 (0x401ff000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > libsasl.so.7 => /usr/lib/libsasl.so.7 (0x4033c000) > libdl.so.2 => /lib/libdl.so.2 (0x40347000) > libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x4034a000) > libcrypt.so.1 => /lib/libcrypt.so.1 (0x40352000) > libpam.so.0 => /lib/libpam.so.0 (0x4037f000) > > The output from /proc/<pid>/maps is attached. > > The (short version) of the linking is simply like this: > > gcc -o server <OBJECTS> `glib-config --libs gthread` <LIBRARIES> > > > Did you manage to get a small standalone program to reproduce the > > problem? > > Not yet. > > \David |
From: Robert W. <rj...@du...> - 2003-04-06 18:48:07
|
> Anyone have a reliable check easily to hand? Yeugh. I don't know if this is reliable, but pthread_tryjoin_np is implemented in nptl but not in the original pthread stuff. Perhaps a check for that will let you know? It will certainly let you know if pthread_tryjoin_np is implemented, but you might allow yourself to infer from that that it's nptl... :-) 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-06 13:14:24
|
Greetings, all. I'm trying to add support to V for R H 9, and it nearly works. I need a configure (autoconf, etc) check to establish whether V is being built on a system which uses NPTL (Native Posix Threads Library) as opposed to the older LinuxThreads library. So far R H 9 is the only distro I'm aware of that uses NPTL. Problem is: I have a set of patches which does appear to make V work on R H 9, but they break all other systems. So I need a configure test to distinguish NPTL-based systems from LinuxThreads-based systems. Anyone have a reliable check easily to hand? J |
From: Julian S. <js...@ac...> - 2003-04-05 09:32:41
|
On Saturday 05 April 2003 9:25 am, you wrote: > HI: > I've been using valgrind for just few days, and it's done well in > one-thread environment,but when I used it in mutil-threads condition,i got > some problem.Maybe i use it wrongly,but i don't get where it is. in this > case,when i link programme with librt.so and libpthread.so and use valgrind > to find memory leak, i could always get some error message like followed: > error: /lib/librt.so.1: symbol __pthread_clock_settime, version > GLIBC_PRIVATE not defined in file libpthread.so.0 with link time reference > I have modifed the LD_PRELOAD var in /usr/local/bin/valgrind shell file,and > make sure ld load our modified libphread.so first. valgrind version: 1.9.4 > My compiler: g++ 2.96. > LD_PRELOAD in /usr/local/bin/valgind: 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. You might 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. J |
From: chen y. <ch...@ga...> - 2003-04-05 09:22:11
|
SEk6DQpJJ3ZlIGJlZW4gdXNpbmcgdmFsZ3JpbmQgZm9yIGp1c3QgZmV3IGRheXMsIGFuZCBpdCdz IGRvbmUgd2VsbCBpbiBvbmUtdGhyZWFkIGVudmlyb25tZW50LGJ1dCB3aGVuIEkgdXNlZCBpdCBp biBtdXRpbC10aHJlYWRzIGNvbmRpdGlvbixpIGdvdCBzb21lIHByb2JsZW0uTWF5YmUgaSB1c2Ug aXQgd3JvbmdseSxidXQgaSBkb24ndCBnZXQgd2hlcmUgaXQgaXMuDQppbiB0aGlzIGNhc2Usd2hl biBpIGxpbmsgcHJvZ3JhbW1lIHdpdGggbGlicnQuc28gYW5kIGxpYnB0aHJlYWQuc28gYW5kIHVz ZSB2YWxncmluZCB0byBmaW5kIG1lbW9yeSBsZWFrLCBpIGNvdWxkIGFsd2F5cyBnZXQgc29tZSBl cnJvciBtZXNzYWdlIGxpa2UgZm9sbG93ZWQ6IA0KZXJyb3I6IC9saWIvbGlicnQuc28uMTogc3lt Ym9sIF9fcHRocmVhZF9jbG9ja19zZXR0aW1lLCB2ZXJzaW9uIEdMSUJDX1BSSVZBVEUgbm90IGRl ZmluZWQgaW4gZmlsZSBsaWJwdGhyZWFkLnNvLjAgd2l0aCBsaW5rIHRpbWUgcmVmZXJlbmNlDQog ICAgSSBoYXZlIG1vZGlmZWQgdGhlIExEX1BSRUxPQUQgdmFyIGluIC91c3IvbG9jYWwvYmluL3Zh bGdyaW5kIHNoZWxsIGZpbGUsYW5kIG1ha2Ugc3VyZSBsZCBsb2FkIG91ciBtb2RpZmllZCBsaWJw aHJlYWQuc28gZmlyc3QuDQp2YWxncmluZCB2ZXJzaW9uOiAxLjkuNA0KTXkgY29tcGlsZXI6IGcr KyAyLjk2Lg0KTERfUFJFTE9BRCBpbiAvdXNyL2xvY2FsL2Jpbi92YWxnaW5kOiAkVkFMR1JJTkQv JHNraW5fc286JFZBTEdSSU5EL3ZhbGdyaW5kLnNvOiRWQUxHUklORC9saWJwdGhyZWFkLnNvOiRM RF9QUkVMT0FEDQoNClRoYW5rcyBpbiBhZHZhbmNlDQpjaGVueWkgDQo= |
From: Dominic M. <dma...@ai...> - 2003-04-04 22:18:54
|
On Fri, 4 Apr 2003, Julian Seward wrote: > > Hi. Yes, 1.9.4 does have an obscure bug in the handling of floating > point conditional code sometimes. I've fixed it in cvs and I hope to > get it out to the world by shipping 1.9.5 at the weekend, or soon > thereafter. In the meantime I attach a patch with the fix -- easy, > you just need to delete two lines of code. > > It would be good if you could confirm that it works. Yep, that fixes it. Thanks! > Thanks for chasing down a small example, even though I didn't use it > -- you've no idea how much that helps. Reproducing problems that people > report is the #1 problem we have in debugging V; once we reproduce a > problem, tracking it down is simple. I understand all too well. :) Regards, Dominic > J > > Index: coregrind/vg_from_ucode.c > =================================================================== > RCS file: /cvsroot/valgrind/valgrind/coregrind/vg_from_ucode.c,v > retrieving revision 1.41 > retrieving revision 1.42 > diff -u -3 -p -r1.41 -r1.42 > --- coregrind/vg_from_ucode.c 26 Mar 2003 21:08:00 -0000 1.41 > +++ coregrind/vg_from_ucode.c 26 Mar 2003 23:43:57 -0000 1.42 > @@ -3412,8 +3412,6 @@ static void emitUInstr ( UCodeBlock* cb, > case FPU: > vg_assert(u->tag1 == Lit16); > vg_assert(u->tag2 == NoValue); > - if (anyFlagUse ( u )) > - emit_get_eflags(); > if (!(*fplive)) { > emit_get_fpu_state(); > *fplive = True; > > > On Friday 04 April 2003 6:57 pm, Dominic Mazzoni wrote: > > Hi, > > > > I've been using valgrind for about six months, and it's been wonderful to > > have. I was spoiled having access to purify on Solaris machines for a > > while, and missed having something similar on Linux. Many thanks to > > Julian Seward and everyone else who contributed to its development. > > > > I've included a very small program that generates different output when > > it's run through valgrind. I noticed the error while I was debugging a > > function to quickly check if an array of single-precision floats has any > > NaNs in it - it turns out that doing a bitwise test is 2-3x faster than > > calling the finite() function. > > > > Anyway, the error only occurs if you compile it with the options: > > > > gcc -O2 -mcpu=pentiumpro -march=pentiumpro > > > > However, the exact same error occurs whether I compile the program with > > gcc 2.96 (RedHat 7.3's version) or gcc 3.2. > > > > The correct output of the program is "0.000000". When run under valgrind > > 1.9.4, it outputs "1.000000". > > > > I hope this helps! It's easy enough for me to work around, but I can only > > guess that this is probably the symptom of a bug that could manifest > > itself in other ways. > > > > - Dominic > > > > #include <stdio.h> > > > > int main(int argc, char **argv) > > { > > union { > > float a[2]; > > int b[2]; > > } u; > > > > u.a[0] = 0.0 / 0.0; > > u.a[1] = ((*u.b & 0x7FC00000) != 0x7FC00000); > > printf("%f\n", u.a[1]); > > > > return 0; > > } > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: ValueWeb: > > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > > No other company gives more support or power for your dedicated server > > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > > _______________________________________________ > > Valgrind-users mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > |
From: John R. <re...@cs...> - 2003-04-04 21:57:25
|
> Design for debuggability / verifiability, I say. Automated debugging > is the way to go. Yep -- for example about a year ago I was coding a tricky algorithm that happily lended itself to testing vs. a simulator using random inputs. After I finished finding bugs in my implementation there was one more bug left that turned out to be an error in the original specification of the algorithm! Details on page 12 of this paper if anyone is interested :). http://www.cs.utah.edu/flux/papers/spak-flux-tn-02-01/regehr-rtss02.pdf John |
From: <cha...@ya...> - 2003-04-04 21:11:18
|
Hi, I wonder if there are issues about profiling dinamically loaded plugins? valgrind --skin=cachegrind doesnt seem to produce any relevant info about code in those plugins, only code in statically linked libraries Greetings (btw: im using valgrind 1.9.2, gcc 3.2, redhat 7.2) ------------ ¡Internet GRATIS es Yahoo! Conexión! Usuario "yahoo", contraseña "yahoo". Desde Buenos Aires, 4004-1010. Otras ciudades: http://conexion.yahoo.com.ar/avanzados.html |
From: Julian S. <js...@ac...> - 2003-04-04 21:06:41
|
On Friday 04 April 2003 8:17 pm, John Regehr wrote: > > -- you've no idea how much that helps. Reproducing problems that people > > report is the #1 problem we have in debugging V; once we reproduce a > > problem, tracking it down is simple. > > Is it just reproducing the problem that's hard, or do you mean > "reproducing in a reasonable sized program"? Reproducing it at all. Quite often we get reports of the form I have a 1/2 million line fortran program for doing geophysics calculations. Under some obscure circumstances, this causes V to bomb out with ... assertion failure. I am running on MutantLinux 12.34.567 (with foobar-1.9 patch) and the code is compiled by ExpensiveRealMoneyCompiler v 41.97. Our code is proprietary, so unfortunately we can't send you the source. Can you help us? and in these circumstances there's practically nothing we can do apart from note the bug and hope that someone finds a more tractable test case for it. Even if we could have the sources, setting up the precise environment to repro it is very time consuming, and we all have day jobs (etc). Interestingly, one solution to the above is for the bug reporter to make me an account on their machine and allow me to ssh in, so I can reproduce the bug in-place. This has proved very effective in the half-dozen or so times I've done it, and I appreciate the trust of those who allow it. I bet not many people can say they have used emacs at a distance of 12000 miles -- the most recent example of this, the bug was is New Zealand, and I'm in the UK. > If the latter, then there are techniques that might be able to help. > They basically perform a space-wise or time-wise binary search in order to > narrow down the problem, exploiting the fact that we have a known-correct > implementation of an x86. Yes, that's how V was debugged in the first place. I knew from the start that making the virtual CPU work properly would be a problem. So a fundamental design decision was that the program, when run on valgrind, had a memory layout which allows switching over to the real CPU at any point. By changing the switchover point, you can do a binary search to find the exact basic block which is being mistranslated. This is controlled by the --stop-after= flag. Without that, V would never have worked. Design for debuggability / verifiability, I say. Automated debugging is the way to go. J |
From: Jeremy F. <je...@go...> - 2003-04-04 20:22:28
|
On Fri, 2003-04-04 at 11:58, Julian Seward wrote: > report is the #1 problem we have in debugging V; once we reproduce a > problem, tracking it down is simple. ^ often J |
From: John R. <re...@cs...> - 2003-04-04 20:17:50
|
> -- you've no idea how much that helps. Reproducing problems that people > report is the #1 problem we have in debugging V; once we reproduce a > problem, tracking it down is simple. Is it just reproducing the problem that's hard, or do you mean "reproducing in a reasonable sized program"? If the latter, then there are techniques that might be able to help. They basically perform a space-wise or time-wise binary search in order to narrow down the problem, exploiting the fact that we have a known-correct implementation of an x86. I saw a great implementation of this idea presented by Jim Gray one time. The goal was to flush out bugs in SQL implementations. They would repeatedly generate these massive random queries and feed them to four or five databases until they found a query that did not return identical results across the databases. They then pruned the parse tree that generated the query until they found the smallest query that elicited different answers from different databases, at which point the problem was pretty obvious. Something similar could be done with Valgrind I think. I'm not sure that generating random C or asm programs would work, but maybe it's possible to turn Valgrind on and off during the execution of a program? This would lead to a strategy where we are searching for the briefest application of Valgrind that gives a different result than a native x86. Again, the problem should be obvious at that point. John |
From: Julian S. <js...@ac...> - 2003-04-04 19:49:56
|
Hi. Yes, 1.9.4 does have an obscure bug in the handling of floating point conditional code sometimes. I've fixed it in cvs and I hope to get it out to the world by shipping 1.9.5 at the weekend, or soon thereafter. In the meantime I attach a patch with the fix -- easy, you just need to delete two lines of code. It would be good if you could confirm that it works. Thanks for chasing down a small example, even though I didn't use it -- you've no idea how much that helps. Reproducing problems that people report is the #1 problem we have in debugging V; once we reproduce a problem, tracking it down is simple. J Index: coregrind/vg_from_ucode.c =================================================================== RCS file: /cvsroot/valgrind/valgrind/coregrind/vg_from_ucode.c,v retrieving revision 1.41 retrieving revision 1.42 diff -u -3 -p -r1.41 -r1.42 --- coregrind/vg_from_ucode.c 26 Mar 2003 21:08:00 -0000 1.41 +++ coregrind/vg_from_ucode.c 26 Mar 2003 23:43:57 -0000 1.42 @@ -3412,8 +3412,6 @@ static void emitUInstr ( UCodeBlock* cb, case FPU: vg_assert(u->tag1 == Lit16); vg_assert(u->tag2 == NoValue); - if (anyFlagUse ( u )) - emit_get_eflags(); if (!(*fplive)) { emit_get_fpu_state(); *fplive = True; On Friday 04 April 2003 6:57 pm, Dominic Mazzoni wrote: > Hi, > > I've been using valgrind for about six months, and it's been wonderful to > have. I was spoiled having access to purify on Solaris machines for a > while, and missed having something similar on Linux. Many thanks to > Julian Seward and everyone else who contributed to its development. > > I've included a very small program that generates different output when > it's run through valgrind. I noticed the error while I was debugging a > function to quickly check if an array of single-precision floats has any > NaNs in it - it turns out that doing a bitwise test is 2-3x faster than > calling the finite() function. > > Anyway, the error only occurs if you compile it with the options: > > gcc -O2 -mcpu=pentiumpro -march=pentiumpro > > However, the exact same error occurs whether I compile the program with > gcc 2.96 (RedHat 7.3's version) or gcc 3.2. > > The correct output of the program is "0.000000". When run under valgrind > 1.9.4, it outputs "1.000000". > > I hope this helps! It's easy enough for me to work around, but I can only > guess that this is probably the symptom of a bug that could manifest > itself in other ways. > > - Dominic > > #include <stdio.h> > > int main(int argc, char **argv) > { > union { > float a[2]; > int b[2]; > } u; > > u.a[0] = 0.0 / 0.0; > u.a[1] = ((*u.b & 0x7FC00000) != 0x7FC00000); > printf("%f\n", u.a[1]); > > return 0; > } > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
From: Dominic M. <dma...@ai...> - 2003-04-04 18:53:32
|
Hi, I've been using valgrind for about six months, and it's been wonderful to have. I was spoiled having access to purify on Solaris machines for a while, and missed having something similar on Linux. Many thanks to Julian Seward and everyone else who contributed to its development. I've included a very small program that generates different output when it's run through valgrind. I noticed the error while I was debugging a function to quickly check if an array of single-precision floats has any NaNs in it - it turns out that doing a bitwise test is 2-3x faster than calling the finite() function. Anyway, the error only occurs if you compile it with the options: gcc -O2 -mcpu=pentiumpro -march=pentiumpro However, the exact same error occurs whether I compile the program with gcc 2.96 (RedHat 7.3's version) or gcc 3.2. The correct output of the program is "0.000000". When run under valgrind 1.9.4, it outputs "1.000000". I hope this helps! It's easy enough for me to work around, but I can only guess that this is probably the symptom of a bug that could manifest itself in other ways. - Dominic #include <stdio.h> int main(int argc, char **argv) { union { float a[2]; int b[2]; } u; u.a[0] = 0.0 / 0.0; u.a[1] = ((*u.b & 0x7FC00000) != 0x7FC00000); printf("%f\n", u.a[1]); return 0; } |
From: Jeffrey S. <fe...@xi...> - 2003-04-04 17:42:47
|
nah, was not aware of them. thanks for the pointer. Jeff On Fri, 2003-04-04 at 03:05, Julian Seward wrote: > You're aware of valgui and gnogrind, both of which are GUI > projects for V, yes? I think they are both at sourceforge. > > J > > On Friday 04 April 2003 4:16 am, Biswapesh Chattopadhyay wrote: > > On Fri, 2003-04-04 at 00:14, Jeffrey Stedfast wrote: > > > I've actually already started working on a valgrind frontend for Gtk. > > > > > > http://primates.ximian.com/~fejj/alleyoop-0.1.tar.gz > > > > > > I don't think that's the latest sources, but it should be close enough > > > for you to get a feel for what I am doing. > > > > Cool ! Thanks for the pointer. That's almost exactly what I was looking > > for. > > > > > -- > > > Biswa. > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: ValueWeb: > > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > > No other company gives more support or power for your dedicated server > > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > > _______________________________________________ > > Valgrind-users mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-users -- Jeffrey Stedfast Evolution Hacker - Ximian, Inc. fe...@xi... - www.ximian.com |
From: Julian S. <js...@ac...> - 2003-04-04 07:57:17
|
You're aware of valgui and gnogrind, both of which are GUI projects for V, yes? I think they are both at sourceforge. J On Friday 04 April 2003 4:16 am, Biswapesh Chattopadhyay wrote: > On Fri, 2003-04-04 at 00:14, Jeffrey Stedfast wrote: > > I've actually already started working on a valgrind frontend for Gtk. > > > > http://primates.ximian.com/~fejj/alleyoop-0.1.tar.gz > > > > I don't think that's the latest sources, but it should be close enough > > for you to get a feel for what I am doing. > > Cool ! Thanks for the pointer. That's almost exactly what I was looking > for. > > > -- > > Biswa. > > ------------------------------------------------------- > This SF.net email is sponsored by: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
From: Biswapesh C. <bis...@tc...> - 2003-04-04 04:10:11
|
On Fri, 2003-04-04 at 00:14, Jeffrey Stedfast wrote: > I've actually already started working on a valgrind frontend for Gtk. > > http://primates.ximian.com/~fejj/alleyoop-0.1.tar.gz > > I don't think that's the latest sources, but it should be close enough > for you to get a feel for what I am doing. Cool ! Thanks for the pointer. That's almost exactly what I was looking for. > -- > Biswa. > |
From: Jeffrey S. <fe...@xi...> - 2003-04-03 18:47:19
|
I've actually already started working on a valgrind frontend for Gtk. http://primates.ximian.com/~fejj/alleyoop-0.1.tar.gz I don't think that's the latest sources, but it should be close enough for you to get a feel for what I am doing. On Thu, 2003-04-03 at 02:16, Biswapesh Chattopadhyay wrote: > Hi > > I was thinking of writing a GTK+ GUI on top of valgrind (mainly for the > addrcheck skin for now) and integrating it with Anjuta. So, my questions > are: > > 1. What is the recommended method for writing a GUI on top of valgrind ? > Should I just fork()/exec() the process and parse the output this is how I did it :-) however... speaking of front-ends for valgrind - would it be possible for the valgrind developers to add a switch such as --full-src-path or some such that would give the full path name for the src file in the error log output? currently it only gives the basename of the src file containing the brokeness. I've taken a look at adding this myself (to 1.0.4) but got lost in the valgrind sources for parsing ELF (symtab2.c or some such if I recall correctly). from my limited understanding of ELF (mostly from playing with libbfd), the debugging symbols which would give what I want (full src path) lies within the "text" section - but it appears that is not what valgrind uses (probably for a good reason, just that I don't know what that reason is). the other path I was thinking of following was to use bfd myself, but that means that I would have to figure out which .so each address was in. it also means (logically) that I would have to open each of the dependency .so's in libbfd so that I could extract the debugging symbols I needed. kinda yuck, but ya gotta do what ya gotta do I guess :-) > Or, is it > possible to use valgrind as a loadable library in some way ? not that I know of. > > 2. I'm having some problems while running large GTK+ programs (e.g. > anjuta). For example, anjuta crashes on startup unless you pass the > '--no-splash' flag. Then, some gconf errors occur only when running > through valgrind. Are these known issues, and are they on the way to > getting solved ? are you using --alignment=8 ? I had to do this when valgrinding evolution. Jeff > > FWIW, I'm using RH 8.0 with GNOME 2.2 CVS. > > Thanks in advance. -- Jeffrey Stedfast Evolution Hacker - Ximian, Inc. fe...@xi... - www.ximian.com |
From: Biswapesh C. <bis...@tc...> - 2003-04-03 07:11:40
|
Hi I was thinking of writing a GTK+ GUI on top of valgrind (mainly for the addrcheck skin for now) and integrating it with Anjuta. So, my questions are: 1. What is the recommended method for writing a GUI on top of valgrind ? Should I just fork()/exec() the process and parse the output Or, is it possible to use valgrind as a loadable library in some way ? 2. I'm having some problems while running large GTK+ programs (e.g. anjuta). For example, anjuta crashes on startup unless you pass the '--no-splash' flag. Then, some gconf errors occur only when running through valgrind. Are these known issues, and are they on the way to getting solved ? FWIW, I'm using RH 8.0 with GNOME 2.2 CVS. Thanks in advance. -- Biswa. |
From: <da...@2g...> - 2003-04-03 06:50:39
|
Quoting Jeremy Fitzhardinge <je...@go...>: > On Wed, 2003-04-02 at 10:28, David Eriksson wrote: > > > Strace stops in poll, and if I attach to the server process with gdb I > > get this stacktrace: > > > > (gdb) bt > > #0 0x40183272 in vgPlain_do_syscall () from > > /usr/local/lib/valgrind/valgrind.so > > #1 0x4023c4d0 in __JCR_LIST__ () from /usr/lib/libglib-1.2.so.0 > > #2 0x40170c97 in poll (__fds=0x4223bf3c, __nfds=0x2, __timeout=0xea60) > > at vg_intercept.c:194 > > #3 0x4022a3cb in g_main_poll () from /usr/lib/libglib-1.2.so.0 > > #4 0x40229c95 in g_main_iterate () from /usr/lib/libglib-1.2.so.0 > > #5 0x4022a0f4 in g_main_run () from /usr/lib/libglib-1.2.so.0 > > #6 0x0804c671 in main (argc=0x0, argv=0xbfffe8e4) at smaccd.c:616 > > #7 0x403d3907 in __libc_start_main () from /lib/libc.so.6 > > Hm, looks like the vg_intercept stuff isn't working - it's catching > poll, but it isn't passing it into the threads library properly. What > does ldd <your program> say? What is in /proc/<pid>/maps when you run > it? What does the link command line look like? ldd says this: libgthread-1.2.so.0 => /usr/lib/libgthread-1.2.so.0 (0x4002a000) libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x4002e000) libpthread.so.0 => /lib/libpthread.so.0 (0x40054000) libldap_r.so.2 => /usr/lib/libldap_r.so.2 (0x400a6000) liblber.so.2 => /usr/lib/liblber.so.2 (0x400d4000) libradiusclient.so.0 => /usr/local/radiusclient/lib/libradiusclient.so.0 (0x400df000) libssl.so.2 => /lib/libssl.so.2 (0x400e8000) libcrypto.so.2 => /lib/libcrypto.so.2 (0x40119000) libresolv.so.2 => /lib/libresolv.so.2 (0x401ed000) libc.so.6 => /lib/libc.so.6 (0x401ff000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) libsasl.so.7 => /usr/lib/libsasl.so.7 (0x4033c000) libdl.so.2 => /lib/libdl.so.2 (0x40347000) libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x4034a000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x40352000) libpam.so.0 => /lib/libpam.so.0 (0x4037f000) The output from /proc/<pid>/maps is attached. The (short version) of the linking is simply like this: gcc -o server <OBJECTS> `glib-config --libs gthread` <LIBRARIES> > Did you manage to get a small standalone program to reproduce the > problem? Not yet. \David |
From: Jeremy F. <je...@go...> - 2003-04-02 19:22:31
|
On Wed, 2003-04-02 at 10:28, David Eriksson wrote: > Strace stops in poll, and if I attach to the server process with gdb I > get this stacktrace: > > (gdb) bt > #0 0x40183272 in vgPlain_do_syscall () from > /usr/local/lib/valgrind/valgrind.so > #1 0x4023c4d0 in __JCR_LIST__ () from /usr/lib/libglib-1.2.so.0 > #2 0x40170c97 in poll (__fds=0x4223bf3c, __nfds=0x2, __timeout=0xea60) > at vg_intercept.c:194 > #3 0x4022a3cb in g_main_poll () from /usr/lib/libglib-1.2.so.0 > #4 0x40229c95 in g_main_iterate () from /usr/lib/libglib-1.2.so.0 > #5 0x4022a0f4 in g_main_run () from /usr/lib/libglib-1.2.so.0 > #6 0x0804c671 in main (argc=0x0, argv=0xbfffe8e4) at smaccd.c:616 > #7 0x403d3907 in __libc_start_main () from /lib/libc.so.6 Hm, looks like the vg_intercept stuff isn't working - it's catching poll, but it isn't passing it into the threads library properly. What does ldd <your program> say? What is in /proc/<pid>/maps when you run it? What does the link command line look like? Did you manage to get a small standalone program to reproduce the problem? J |
From: David E. <da...@2g...> - 2003-04-02 18:56:33
|
On Wed, 2003-04-02 at 19:53, Jeremy Fitzhardinge wrote: > On Wed, 2003-04-02 at 09:02, David Eriksson wrote: > > For the fun of it, I tried to send a SIGHUP to my process. There is > > singal handler installed with signal() for SIGHUP, which gets executed > > properly. What also happens is that all threads (one for each connection > > that have been made to the server) get to run! > > > > Do you have any ideas? > > > > I will happily provide any more information that may be of interest. > What does strace have to say about your running process? Is it > blocked in a a system call, or does it seem to be spinning away > happily? > > It's possible that the libc poll (or some other blocking system call) > is somehow getting called without being intercepted by Valgrind. Strace stops in poll, and if I attach to the server process with gdb I get this stacktrace: (gdb) bt #0 0x40183272 in vgPlain_do_syscall () from /usr/local/lib/valgrind/valgrind.so #1 0x4023c4d0 in __JCR_LIST__ () from /usr/lib/libglib-1.2.so.0 #2 0x40170c97 in poll (__fds=0x4223bf3c, __nfds=0x2, __timeout=0xea60) at vg_intercept.c:194 #3 0x4022a3cb in g_main_poll () from /usr/lib/libglib-1.2.so.0 #4 0x40229c95 in g_main_iterate () from /usr/lib/libglib-1.2.so.0 #5 0x4022a0f4 in g_main_run () from /usr/lib/libglib-1.2.so.0 #6 0x0804c671 in main (argc=0x0, argv=0xbfffe8e4) at smaccd.c:616 #7 0x403d3907 in __libc_start_main () from /lib/libc.so.6 -- -\- David Eriksson -/- www.2GooD.nu "I personally refuse to use inferior tools because of ideology." - Linus Torvalds |
From: David E. <da...@2g...> - 2003-04-02 18:50:30
|
On Wed, 2003-04-02 at 19:41, Jeff Johnson wrote: > On Wed, Apr 02, 2003 at 07:02:19PM +0200, David Eriksson wrote: > > Hello, > > > > First, the obligatory credits: Thank you very much for writing valgrind! > > > > When I recently subscribed to this mailing list I read a message from > > Nicholas Nethercote where he said that 1.9.4 was more stable and worked > > better than 1.0.4 so I thought I'd give it a try. > > > > However, it seems to me like something has changed between the two > > versions, maybe regarding the combination threads and sockets. > > > > I am running RedHat 8.0, with the latest updates installed: > > > > kernel-2.4.18-27.8.0 > > glibc-2.3.2-4.80 > > gcc-3.2-7 > > > > The application I'm examining with valgrind is a threaded server > > application written in C that uses glib. It is quite large and > > complicated to install, so there is no point in providing it. > > > > I have tried to make a scaled-down example to reproduce my problem. It > > is not finished yet, but I thought that I'll try to describe the problem > > in case anyone has any suggestions: > > > > The server creates a unix socket and makes glib poll() the socket for > > events. A client connects to the server, which accept() the connection > > and creates a new thread for handling the connection. > > > > By using simple "printf debugging" it seems like the the new thread > > never gets scheduled to run in valgrind 1.9.4. > > > > For the fun of it, I tried to send a SIGHUP to my process. There is > > singal handler installed with signal() for SIGHUP, which gets executed > > properly. What also happens is that all threads (one for each connection > > that have been made to the server) get to run! > > > > Do you have any ideas? > > FYI: You're running a NPTL capable library with a NPTL deprived kernel. > > Meanwhile, prefix your valgrind command with > LD_ASSUME_KERNEL=2.2.5 valgrind ... > to force use of Good Old libpthread. Well, pthread is never loaded when using valgrind as valgrind maintains its own thread scheduling: ... ==29456== Reading syms from /usr/local/lib/valgrind/libpthread.so ... -- -\- David Eriksson -/- www.2GooD.nu "I personally refuse to use inferior tools because of ideology." - Linus Torvalds |