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
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
1
|
2
(9) |
3
(14) |
4
|
5
(2) |
6
|
|
7
|
8
(2) |
9
(5) |
10
(4) |
11
(1) |
12
(14) |
13
(1) |
|
14
|
15
(4) |
16
(3) |
17
(7) |
18
(2) |
19
|
20
|
|
21
|
22
(2) |
23
(2) |
24
(23) |
25
(15) |
26
(7) |
27
(2) |
|
28
(7) |
29
(2) |
30
(8) |
31
(5) |
|
|
|
|
From: Ashley P. <as...@qu...> - 2006-05-12 08:53:48
|
On Fri, 2006-05-12 at 07:10 +0100, Darryl Miles wrote: > But.... this memory was allocated with calloc(), so it was initialised > to zero. If it had been allocated with malloc() the warning would make > sense. Can I disable this class of error specifically for the calloc() > case ? One could argue this should be default behaviour and a -pedantic > like option could be added to emit this class of problem. That is how it should work already, the allocation functions have a "zeroed" bit associated with them, it's set for calloc and not for malloc. As your error is only 27 bytes into 16k and I doubt you are sending 16 of blank data! it's likely that what you copied into the buffer was itself uninitialised. > Is it possible to directly manipulate the A and V bits of memcheck from > within the program by linking with some sort of valgrind stub library > which could communicate with valgrind at runtime. I could do this with > Checker GCC. So that I can purposefully invalidate (or validate) an > area of memory. In fact this was exactly how the libc stubs of Checker > GCC worked, and it is my application library wrapper I wish to port to > valgrind. Have a look in <prefix>/valgrind/memcheck.h, in particular at the VALGRIND_MAKE_READABLE() and VALGRIND_MAKE_NOACCESS() macros. These are a little heavy handed though as they work on both the V and A bits at the same time, I know there was talk of macros that only work on the V bits without affecting the A bits but it's not finished yet. SVN code has more macros of this nature if your serious about it... That said I'm not 100% sure what you are trying to do here, most, *almost all* people get by without needing to manipulate the bits directly, are you sure you are tackling the problem in the right way? Ashley, |
|
From: Darryl M. <dar...@ne...> - 2006-05-12 06:10:24
|
I am trying to migrate some code from the old GCC checker to valgrind as part of the learning curve I fired it up over Mozilla. If I interpret (the output at end of email) correctly the system call write() has uninitialized data that is included in the scope of its length, so the kernel maybe expected to perform a read operation on one or more bytes of uninitialised data. But.... this memory was allocated with calloc(), so it was initialised to zero. If it had been allocated with malloc() the warning would make sense. Can I disable this class of error specifically for the calloc() case ? One could argue this should be default behaviour and a -pedantic like option could be added to emit this class of problem. Is it possible to directly manipulate the A and V bits of memcheck from within the program by linking with some sort of valgrind stub library which could communicate with valgrind at runtime. I could do this with Checker GCC. So that I can purposefully invalidate (or validate) an area of memory. In fact this was exactly how the libc stubs of Checker GCC worked, and it is my application library wrapper I wish to port to valgrind. Thanks Darryl ==31294== ==31294== Syscall param write(buf) points to uninitialised byte(s) ==31294== at 0x125A815B: (within /lib64/libpthread-2.3.5.so) ==31294== by 0x136D3BDE: (within /usr/X11R6/lib64/libX11.so.6.2) ==31294== by 0x136B7BEA: (within /usr/X11R6/lib64/libX11.so.6.2) ==31294== by 0x13694F0F: XCheckWindowEvent (in /usr/X11R6/lib64/libX11.so.6.2) ==31294== by 0x1AFA6A0D: nsWindow::OnMotionNotifyEvent(_GtkWidget*, _GdkEventMotion*) (in /data/src/mozilla/widget/src/gtk2/libwidget_gtk2.so) ==31294== by 0x1AFA768F: motion_notify_event_cb(_GtkWidget*, _GdkEventMotion*) (in /data/src/mozilla/widget/src/gtk2/libwidget_gtk2.so) ==31294== by 0x128BAE61: (within /usr/lib64/libgtk-x11-2.0.so.0.600.10) ==31294== by 0x132B927B: g_closure_invoke (in /usr/lib64/libgobject-2.0.so.0.600.6) ==31294== by 0x132C62E9: (within /usr/lib64/libgobject-2.0.so.0.600.6) ==31294== by 0x132C754A: g_signal_emit_valist (in /usr/lib64/libgobject-2.0.so.0.600.6) ==31294== by 0x132C7BC1: g_signal_emit (in /usr/lib64/libgobject-2.0.so.0.600.6) ==31294== by 0x1297F4A7: (within /usr/lib64/libgtk-x11-2.0.so.0.600.10) ==31294== Address 0x14E06A4B is 27 bytes inside a block of size 16384 alloc'd ==31294== at 0x11B211FD: calloc (vg_replace_malloc.c:279) ==31294== by 0x136A814B: XOpenDisplay (in /usr/X11R6/lib64/libX11.so.6.2) ==31294== by 0x12BCCE38: gdk_display_open (in /usr/lib64/libgdk-x11-2.0.so.0.600.10) ==31294== by 0x12BB287D: gdk_display_open_default_libgtk_only (in /usr/lib64/libgdk-x11-2.0.so.0.600.10) ==31294== by 0x128B8944: gtk_init_check (in /usr/lib64/libgtk-x11-2.0.so.0.600.10) ==31294== by 0x128B895B: gtk_init (in /usr/lib64/libgtk-x11-2.0.so.0.600.10) ==31294== by 0x40B86F: main (in /data/src/mozilla/xpfe/bootstrap/seamonkey-bin) |
|
From: Andy H. <And...@ra...> - 2006-05-12 04:17:27
|
Hello, I'm having a problem with callgrind on AMD64. My app cores with: ** glibc detected *** double free or corruption (out) 0X0000000588e010 *** I'm 99% sure that I'm not doing a double free where it cores. This only happens on AMD64. On a 4-way 32 bit XEON its fine. Valgrind does not turn up any errors either. I'm using callgrind-0.10.1 and valgrind-3.1.0 Any known issues with AMD64? Thanks, Andy |
|
From: T. S. N. <tse...@ya...> - 2006-05-12 01:43:25
|
Dear team,
I am trying to find a stack usage for a webserver
when we get HTTP request.
First the webserver was started using the valgrind
tool and HTTP get is given to webserver after sleep of
10 secs and then a kill signal to valgrind is given to
stop and find the stack usage during the message
transaction. The following are the commands which I
have used.
valgrind --tool=massif --heap=no --heap-admin=no
./webs &
sleep 10
./wget http://192.168.8.20/goform/getVariable21
sleep 10
kill -15 `/sbin/pidof valgrind`
After all these commands executed, three files
generated *.hp, *.ps and *.txt. None of the files
shows change in stack usage after 10 secs(after HTTP
request is given).
By looking at the source code of the webserver it was
found that, there are function calls with arguments
after getting HTTP request but it not showing any
change is stack usage after 10 secs. Kindly let me
know your comments.
Regards,
Senthil.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam
protection around
http://mail.yahoo.com
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
|
|
From: lcq_yapulan <lcq...@16...> - 2006-05-11 17:57:29
|
confirm 353583 |
|
From: Julian S. <js...@ac...> - 2006-05-10 22:13:23
|
Can you figure out approximately what number to set this to, and let us know? J On Wednesday 10 May 2006 15:59, Joachim Bauernberger wrote: > Thanks for the hint! > We were planning on removing the assert altogether, but weren't sure of any > sideeffects. > Regards, > Joachim Bauernberger > > On 5/10/06, Julian Seward <js...@ac...> wrote: > > It may be that there is no problem, but just that the 2000000 limit > > in the assert is too low given the huge size of the object. One way to > > find out is to increase the limit to number until the assertion no > > longer fires. Probably worth trying. > > > > J > > > > On Wednesday 10 May 2006 15:49, Joachim Bauernberger wrote: > > > Hi Julian, > > > > > > we have this in valgrind 3.0.1 and 3.1.1. > > > Unfortunately this the shared lib is some lib supplied by third-party > > > > and I > > > > > am unable to give it out :-( > > > > > > On 5/5/06, Julian Seward <js...@ac...> wrote: > > > > Which version of Valgrind is this with? And what CPU ? > > > > > > > > Can you make the shared lib available so we can look at what > > > > the debug info reader is doing? > > > > > > > > J > > > > > > > > On Friday 05 May 2006 08:25, Joachim Bauernberger wrote: > > > > > Dear list, > > > > > > > > > > we get the following assert when using valgrind: > > > > > > > > > > --24267-- Reading syms from > > > > > /utran/ngrncOmodel/lib/linux/debug/libcschnappi.so (0x1C491000) > > > > > valgrind: symtab.c:377 (vgModuleLocal_addCfiSI): Assertion > > > > 'cfisi->len > > > > > > 0 > > > > > > > > > && cfisi->len < 2000000' failed > > > > > > > > > > could someone tell me how I can interpret this assert and whether > > > > > it > > > > > > > > would > > > > > > > > > be safe to remove it? > > > > > > > > > > our program uses some shared libs and one of them is extremely big > > > > (200 > > > > > > > MB+). The assert happens during reading the symbols from this huge > > > > > > > > shared > > > > > > > > > lib. > > > > > > > > > > thanks, > > > > > joachim > > > > > > -- > > > http://www.bauernberger.de/ > > > OpenBC: https://www.openbc.com/hp/Joachim_Bauernberger/ > > > mailto:jo...@ba... > > > ICQ: 214527045 > > > Tel/Fax: +(49)-0-89/1588 3874 > > > HP: +(49)-0-179/674 3611 > > -- > http://www.bauernberger.de/ > OpenBC: https://www.openbc.com/hp/Joachim_Bauernberger/ > mailto:jo...@ba... > ICQ: 214527045 > Tel/Fax: +(49)-0-89/1588 3874 > HP: +(49)-0-179/674 3611 |
|
From: Joachim B. <joa...@gm...> - 2006-05-10 20:27:20
|
Thanks for the hint! We were planning on removing the assert altogether, but weren't sure of any sideeffects. Regards, Joachim Bauernberger On 5/10/06, Julian Seward <js...@ac...> wrote: > > > It may be that there is no problem, but just that the 2000000 limit > in the assert is too low given the huge size of the object. One way to > find out is to increase the limit to number until the assertion no > longer fires. Probably worth trying. > > J > > On Wednesday 10 May 2006 15:49, Joachim Bauernberger wrote: > > Hi Julian, > > > > we have this in valgrind 3.0.1 and 3.1.1. > > Unfortunately this the shared lib is some lib supplied by third-party > and I > > am unable to give it out :-( > > > > On 5/5/06, Julian Seward <js...@ac...> wrote: > > > Which version of Valgrind is this with? And what CPU ? > > > > > > Can you make the shared lib available so we can look at what > > > the debug info reader is doing? > > > > > > J > > > > > > On Friday 05 May 2006 08:25, Joachim Bauernberger wrote: > > > > Dear list, > > > > > > > > we get the following assert when using valgrind: > > > > > > > > --24267-- Reading syms from > > > > /utran/ngrncOmodel/lib/linux/debug/libcschnappi.so (0x1C491000) > > > > valgrind: symtab.c:377 (vgModuleLocal_addCfiSI): Assertion > 'cfisi->len > > > > > > > > > > > 0 > > > > > > > && cfisi->len < 2000000' failed > > > > > > > > could someone tell me how I can interpret this assert and whether i= t > > > > > > would > > > > > > > be safe to remove it? > > > > > > > > our program uses some shared libs and one of them is extremely big > (200 > > > > MB+). The assert happens during reading the symbols from this huge > > > > > > shared > > > > > > > lib. > > > > > > > > thanks, > > > > joachim > > > > -- > > http://www.bauernberger.de/ > > OpenBC: https://www.openbc.com/hp/Joachim_Bauernberger/ > > mailto:jo...@ba... > > ICQ: 214527045 > > Tel/Fax: +(49)-0-89/1588 3874 > > HP: +(49)-0-179/674 3611 > -- http://www.bauernberger.de/ OpenBC: https://www.openbc.com/hp/Joachim_Bauernberger/ mailto:jo...@ba... ICQ: 214527045 Tel/Fax: +(49)-0-89/1588 3874 HP: +(49)-0-179/674 3611 |
|
From: Julian S. <js...@ac...> - 2006-05-10 14:54:54
|
It may be that there is no problem, but just that the 2000000 limit in the assert is too low given the huge size of the object. One way to find out is to increase the limit to number until the assertion no longer fires. Probably worth trying. J On Wednesday 10 May 2006 15:49, Joachim Bauernberger wrote: > Hi Julian, > > we have this in valgrind 3.0.1 and 3.1.1. > Unfortunately this the shared lib is some lib supplied by third-party and I > am unable to give it out :-( > > On 5/5/06, Julian Seward <js...@ac...> wrote: > > Which version of Valgrind is this with? And what CPU ? > > > > Can you make the shared lib available so we can look at what > > the debug info reader is doing? > > > > J > > > > On Friday 05 May 2006 08:25, Joachim Bauernberger wrote: > > > Dear list, > > > > > > we get the following assert when using valgrind: > > > > > > --24267-- Reading syms from > > > /utran/ngrncOmodel/lib/linux/debug/libcschnappi.so (0x1C491000) > > > valgrind: symtab.c:377 (vgModuleLocal_addCfiSI): Assertion 'cfisi->len > > > > > > > > 0 > > > > > && cfisi->len < 2000000' failed > > > > > > could someone tell me how I can interpret this assert and whether it > > > > would > > > > > be safe to remove it? > > > > > > our program uses some shared libs and one of them is extremely big (200 > > > MB+). The assert happens during reading the symbols from this huge > > > > shared > > > > > lib. > > > > > > thanks, > > > joachim > > -- > http://www.bauernberger.de/ > OpenBC: https://www.openbc.com/hp/Joachim_Bauernberger/ > mailto:jo...@ba... > ICQ: 214527045 > Tel/Fax: +(49)-0-89/1588 3874 > HP: +(49)-0-179/674 3611 |
|
From: Joachim B. <joa...@gm...> - 2006-05-10 14:49:15
|
Hi Julian, we have this in valgrind 3.0.1 and 3.1.1. Unfortunately this the shared lib is some lib supplied by third-party and I am unable to give it out :-( On 5/5/06, Julian Seward <js...@ac...> wrote: > > > Which version of Valgrind is this with? And what CPU ? > > Can you make the shared lib available so we can look at what > the debug info reader is doing? > > J > > On Friday 05 May 2006 08:25, Joachim Bauernberger wrote: > > Dear list, > > > > we get the following assert when using valgrind: > > > > --24267-- Reading syms from > > /utran/ngrncOmodel/lib/linux/debug/libcschnappi.so (0x1C491000) > > valgrind: symtab.c:377 (vgModuleLocal_addCfiSI): Assertion 'cfisi->len = > > 0 > > && cfisi->len < 2000000' failed > > > > could someone tell me how I can interpret this assert and whether it > would > > be safe to remove it? > > > > our program uses some shared libs and one of them is extremely big (200 > > MB+). The assert happens during reading the symbols from this huge > shared > > lib. > > > > thanks, > > joachim > -- http://www.bauernberger.de/ OpenBC: https://www.openbc.com/hp/Joachim_Bauernberger/ mailto:jo...@ba... ICQ: 214527045 Tel/Fax: +(49)-0-89/1588 3874 HP: +(49)-0-179/674 3611 |
|
From: Brad H. <br...@fr...> - 2006-05-09 11:45:36
|
On Tuesday 09 May 2006 21:29 pm, James Begley wrote: > On Tue, 2006-05-09 at 21:09 +1000, Brad Hards wrote: > > I'm trying to test QCA, and would like to know about blocks that are > > still reachable. However valgrind doesn't appear to be showing it to me: > > > > $ valgrind --show-reachable=yes ./hexunittest > > I think that you need the --leak-check=full option as well. Try > > valgrind --show-reachable=yes --leak-check=full ./hexunittest Ah, yes. Thanks very much - now works as expected. Brad |
|
From: James B. <ja...@ha...> - 2006-05-09 11:29:36
|
On Tue, 2006-05-09 at 21:09 +1000, Brad Hards wrote: > I'm trying to test QCA, and would like to know about blocks that are still > reachable. However valgrind doesn't appear to be showing it to me: > > $ valgrind --show-reachable=yes ./hexunittest I think that you need the --leak-check=full option as well. Try valgrind --show-reachable=yes --leak-check=full ./hexunittest Cheers, James. James Begley -- Telephone +354-575-2030 Marine Research Institute, Skulagata 4, P.O. Box 1390, 121 Reykjavik, Iceland. |
|
From: Brad H. <br...@fr...> - 2006-05-09 11:10:01
|
I'm trying to test QCA, and would like to know about blocks that are still= =20 reachable. However valgrind doesn't appear to be showing it to me: $ valgrind --show-reachable=3Dyes ./hexunittest =3D=3D12107=3D=3D Memcheck, a memory error detector. =3D=3D12107=3D=3D Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward = et al. =3D=3D12107=3D=3D Using LibVEX rev 1610, a library for dynamic binary trans= lation. =3D=3D12107=3D=3D Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. =3D=3D12107=3D=3D Using valgrind-3.2.0.SVN, a dynamic binary instrumentatio= n=20 framework. =3D=3D12107=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward = et al. =3D=3D12107=3D=3D For more details, rerun with: -v =3D=3D12107=3D=3D ********* Start testing of HexUnitTest ********* Config: Using QTest library 4.1.1, Qt 4.1.2 PASS : HexUnitTest::initTestCase() PASS : HexUnitTest::testHexString() PASS : HexUnitTest::testIncrementalUpdate() PASS : HexUnitTest::testBrokenInput() PASS : HexUnitTest::cleanupTestCase() Totals: 5 passed, 0 failed, 0 skipped ********* Finished testing of HexUnitTest ********* =3D=3D12107=3D=3D =3D=3D12107=3D=3D ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 24 f= rom 1) =3D=3D12107=3D=3D malloc/free: in use at exit: 36 bytes in 2 blocks. =3D=3D12107=3D=3D malloc/free: 3,192 allocs, 3,190 frees, 304,672 bytes all= ocated. =3D=3D12107=3D=3D For counts of detected errors, rerun with: -v =3D=3D12107=3D=3D searching for pointers to 2 not-freed blocks. =3D=3D12107=3D=3D checked 169,864 bytes. =3D=3D12107=3D=3D =3D=3D12107=3D=3D LEAK SUMMARY: =3D=3D12107=3D=3D definitely lost: 0 bytes in 0 blocks. =3D=3D12107=3D=3D possibly lost: 0 bytes in 0 blocks. =3D=3D12107=3D=3D still reachable: 36 bytes in 2 blocks. =3D=3D12107=3D=3D suppressed: 0 bytes in 0 blocks. There is nothing after that. Is this the correct behaviour? I was expecting= to=20 see my two blocks identified... Brad |
|
From: Julian S. <js...@ac...> - 2006-05-09 01:50:50
|
> *** glibc detected *** grompp: realloc(): invalid pointer: 0x04120008 *** Are you sure your program is really correct? It looks like it's passing a bogus pointer to realloc. > can anybody help me with a solution or a workaround plzzzz. Use 'valgrind --tool=memcheck' to find any such bugs, and fix them. Then try again with the profiler. J |
|
From: ganapathy s. <rgs...@re...> - 2006-05-09 01:00:20
|
=0A=0Adear gromacs users,=0A i tried to profile the execution of =
grompp using =0Athe callgrind profiling tool.=0A=0Athe command is as belo=
w.=0A>callgrind -v -dump-every-bb =3D 10000000 grompp -f run4.mdp -c run3.g=
ro -p CAVITY2.top -o run4.tpr =0A =0Athe program aborted with the foll=
owing output.=0A=0A=3D7186=3D=3D Callgrind-0.10.1, a call-graph generating =
cache profiler.=0A=3D=3D7186=3D=3D Copyright (C) 2002-2005, and GNU GPL'd, =
by J.Weidendorfer et al.=0A=3D=3D7186=3D=3D Using LibVEX rev 1575, a librar=
y for dynamic binary translation.=0A=3D=3D7186=3D=3D Copyright (C) 2004-200=
5, and GNU GPL'd, by OpenWorks LLP.=0A=3D=3D7186=3D=3D Using valgrind-3.1.1=
, a dynamic binary instrumentation framework.=0A=3D=3D7186=3D=3D Copyright =
(C) 2000-2005, and GNU GPL'd, by Julian Seward et al.=0A=3D=3D7186=3D=3D Fo=
r more details, rerun with: -v=0A=3D=3D7186=3D=3D=0A=3D=3D7186=3D=3D=0A=3D=
=3D7186=3D=3D For interactive control, run 'callgrind_control -h'.=0A =
:-) G R O M A C S (-:=0A=0A Grave=
l Rubs Often Many Awfully Cauterized Sores=0A=0A =
:-) VERSION 3.3.1 (-:=0A=0A=0A Written by David van der Spoel, Erik=
Lindahl, Berk Hess, and others.=0A Copyright (c) 1991-2000, Universi=
ty of Groningen, The Netherlands.=0A Copyright (c) 2001-2006, T=
he GROMACS development team,=0A check out http://www.gromacs.org=
for more information.=0A=0A This program is free software; you can=
redistribute it and/or=0A modify it under the terms of the GNU Ge=
neral Public License=0A as published by the Free Software Foundatio=
n; either version 2=0A of the License, or (at your option) any =
later version.=0A=0A :-) grompp (-:=0A=0AO=
ption Filename Type Description=0A----------------------------=
--------------------------------=0A -f run4.mdp Input, Opt! grompp=
input file with MD parameters=0A -po mdout.mdp Output grompp i=
nput file with MD parameters=0A -c run3.gro Input Generic st=
ructure: gro g96 pdb tpr tpb tpa=0A xml=
=0A -r conf.gro Input, Opt. Generic structure: gro g96 pdb tpr tpb=
tpa=0A xml=0A -rb conf.gro Input,=
Opt. Generic structure: gro g96 pdb tpr tpb tpa=0A =
xml=0A -n index.ndx Input, Opt. Index file=0A-deshuf d=
eshuf.ndx Output, Opt. Index file=0A -p CAVITY2.top Input Topo=
logy file=0A -pp processed.top Output, Opt. Topology file=0A -o ru=
n4.tpr Output Generic run input: tpr tpb tpa xml=0A -t traj.t=
rr Input, Opt. Full precision trajectory: trr trj=0A -e ener.edr =
Input, Opt. Generic energy: edr ene=0A=0A Option Type Value Descr=
iption=0A------------------------------------------------------=0A -[n=
o]h bool no Print help info and quit=0A -[no]X bool no U=
se dialog box GUI to edit command line options=0A -nice int 0=
Set the nicelevel=0A -[no]v bool yes Be loud and noisy=0A =
-time real -1 Take frame at or first after this time.=0A -=
np int 1 Generate statusfile for # nodes=0A-[no]shuffle bool =
no Shuffle molecules over nodes=0A -[no]sort bool no Sort molecu=
les according to X coordinate=0A-[no]rmvsbds bool yes Remove constant=
bonded interactions with virtual=0A sites=0A =
-load string Releative load capacity of each node on a=0A =
parallel machine. Be sure to use quotes around=0A =
the string, which should contain a number for=0A =
each node=0A -maxwarn int 10 Number of =
warnings after which input processing=0A stops=
=0A-[no]check14 bool no Remove 1-4 interactions without Van der Waal=
s=0A -[no]renum bool yes Renumber atomtypes and minimize number of=
=0A atomtypes=0A=0Acreating statusfile for 1 nod=
e...=0Achecking input for internal consistency...=0AWARNING 1 [file run4.md=
p, line unknown]:=0A For energy conservation with switch/shift potentials,=
rlist should be 0.1=0A to 0.3 nm larger than rcoulomb/rvdw.=0Acalling /li=
b/cpp...=0Aprocessing topology...=0AGenerated 141 of the 1176 non-bonded pa=
rameter combinations=0AExcluding 3 bonded neighbours for POP 32=0Aturning H=
bonds into constraints...=0AExcluding 2 bonded neighbours for SOL 1051=0At=
urning H bonds into constraints...=0AExcluding 3 bonded neighbours for POP =
32=0AExcluding 2 bonded neighbours for SOL 1051=0AExcluding 3 bonded neighb=
ours for POP 32=0AExcluding 2 bonded neighbours for SOL 1051=0AExcluding 3 =
bonded neighbours for POP 32=0AExcluding 2 bonded neighbours for SOL 1051=
=0A*** glibc detected *** grompp: realloc(): invalid pointer: 0x04120008 **=
*=0A=3D=3D=3D=3D=3D=3D=3D Backtrace: =3D=3D=3D=3D=3D=3D=3D=3D=3D=0A/lib/lib=
c.so.6(__libc_realloc+0x2e6)[0x1cff15]=0Agrompp[0x80a926d]=0A=3D=3D=3D=3D=
=3D=3D=3D Memory map: =3D=3D=3D=3D=3D=3D=3D=3D=0A0011f000-00120000 r-xp 001=
1f000 00:00 0=0A00148000-00162000 r-xp 00000000 fd:00 945102 /lib/ld-2.=
3.5.so=0A00162000-00163000 r-xp 00019000 fd:00 945102 /lib/ld-2.3.5.so=
=0A00163000-00164000 rwxp 0001a000 fd:00 945102 /lib/ld-2.3.5.so=0A0016=
a000-0028e000 r-xp 00000000 fd:00 945103 /lib/libc-2.3.5.so=0A0028e000-=
00290000 r-xp 00124000 fd:00 945103 /lib/libc-2.3.5.so=0A00290000-00292=
000 rwxp 00126000 fd:00 945103 /lib/libc-2.3.5.so=0A00292000-00294000 r=
wxp 00292000 00:00 0=0A00296000-002b8000 r-xp 00000000 fd:00 945104 /li=
b/libm-2.3.5.so=0A002b8000-002b9000 r-xp 00021000 fd:00 945104 /lib/lib=
m-2.3.5.so=0A002b9000-002ba000 rwxp 00022000 fd:00 945104 /lib/libm-2.3=
.5.so=0A002bc000-002be000 r-xp 00000000 fd:00 945105 /lib/libdl-2.3.5.s=
o=0A002be000-002bf000 r-xp 00001000 fd:00 945105 /lib/libdl-2.3.5.so=0A=
002bf000-002c0000 rwxp 00002000 fd:00 945105 /lib/libdl-2.3.5.so=0A002d=
7000-003a7000 r-xp 00000000 fd:00 1482512 /usr/X11R6/lib/libX11.so.6.2=
=0A003a7000-003ab000 rwxp 000cf000 fd:00 1482512 /usr/X11R6/lib/libX11.s=
o.6.2=0A003ad000-003bb000 r-xp 00000000 fd:00 1482513 /usr/X11R6/lib/lib=
Xext.so.6.4=0A003bb000-003bc000 rwxp 0000e000 fd:00 1482513 /usr/X11R6/l=
ib/libXext.so.6.4=0A003be000-003c5000 r-xp 00000000 fd:00 1476469 /usr/X=
11R6/lib/libXp.so.6.2=0A003c5000-003c6000 rwxp 00006000 fd:00 1476469 /u=
sr/X11R6/lib/libXp.so.6.2=0A004d4000-004dd000 r-xp 00000000 fd:00 945107 =
/lib/libgcc_s-4.0.0-20050520.so.1=0A004dd000-004de000 rwxp 00009000 fd:00=
945107 /lib/libgcc_s-4.0.0-20050520.so.1=0A005cb000-005d3000 r-xp 0000=
0000 fd:00 1482523 /usr/X11R6/lib/libSM.so.6.0=0A005d3000-005d4000 rwxp =
00007000 fd:00 1482523 /usr/X11R6/lib/libSM.so.6.0=0A005d6000-005ed000 r=
-xp 00000000 fd:00 1482522 /usr/X11R6/lib/libICE.so.6.3=0A005ed000-005ee=
000 rwxp 00016000 fd:00 1482522 /usr/X11R6/lib/libICE.so.6.3=0A005ee000-=
005f0000 rwxp 005ee000 00:00 0=0A005f2000-00847000 r-xp 00000000 fd:00 1475=
394 /usr/X11R6/lib/libXm.so.3.0.2=0A00847000-00860000 rwxp 00255000 fd:0=
0 1475394 /usr/X11R6/lib/libXm.so.3.0.2=0A00860000-00861000 rwxp 0086000=
0 00:00 0=0A04000000-04001000 r-xp 00000000 fd:00 260368 /usr/local/lib=
/valgrind/x86-linux/vgpreload_core.so=0A04001000-04002000 rwxp 00000000 fd:=
00 260368 /usr/local/lib/valgrind/x86-linux/vgpreload_core.so=0A0400200=
0-04003000 rwxp 04002000 00:00 0=0A04004000-0400d000 r-xp 00000000 fd:00 94=
3829 /lib/libnss_files-2.3.5.so=0A0400d000-0400e000 r-xp 00008000 fd:00=
943829 /lib/libnss_files-2.3.5.so=0A0400e000-0400f000 rwxp 00009000 fd=
:00 943829 /lib/libnss_files-2.3.5.so=0A04019000-0401a000 rwxp 04019000=
00:00 0=0A0401a000-0406c000 r-xp 00000000 fd:00 1481939 /usr/X11R6/lib/=
libXt.so.6.0=0A0406c000-04070000 rwxp 00052000 fd:00 1481939 /usr/X11R6/=
lib/libXt.so.6.0=0A04070000-04071000 rwxp 04070000 00:00 0=0A04071000-04087=
000 r-xp 00000000 fd:00 1482558 /usr/X11R6/lib/libXmu.so.6.2=0A04087000-=
04088000 rwxp 00015000 fd:00 1482558 /usr/X11R6/lib/libXmu.so.6.2=0A0408=
8000-04229000 rwxp 04088000 00:00 0=0A07f7d000-07f8f000 r-xp 00000000 fd:00=
945114 /lib/libnsl-2.3.5.so=0A07f8f000-07f90000 r-xp 00011000 fd:00 94=
5114 /lib/libnsl-2.3.5.so=0A07f90000-07f91000 rwxp 00012000 fd:00 94511=
4 /lib/libnsl-2.3.5.so=0A07f91000-07f93000 rwxp 07f91000 00:00 0=0A0804=
8000-081c9000 r-xp 00000000 fd:00 2024902 /usr/local/gromacs/bin/grompp=
=0A081c9000-081d0000 rwxp 00181000 fd:00 2024902 /usr/local/gromacs/bin/=
grompp=0A081d0000-08202000 rwxp 081d0000 00:00 0=0A08202000-082bf000 rwxp 0=
8202000 00:00 0=0A61d4a000-6224a000 rwxp 61d4a000 00:00 0=0A6224a000-6224c0=
00 --xp 6224a000 00:00 0=0A6224c000-6225c000 rwxp 6224c000 00:00 0=0A6225c0=
00-6225e000 --xp 6225c000 00:00 0=0A6225e000-633a4000 rwxp 6225e000 00:00 0=
=0Ab0000000-b0125000 r-xp 00000000 fd:00 650893 /usr/local/lib/valgrind=
/x86-linux/callgrind=0Ab0125000-b012e000 rwxp 00125000 fd:00 650893 /us=
r/local/lib/valgrind/x86-linux/callgrind=0Ab012e000-b074c000 rwxp b012e000 =
00:00 0=0Abea85000-bea93000 rwxp bea85000 00:00 0=0Abfa7f000-bfa95000 rw-p =
bfa7f000 00:00 0 [stack]=0A=3D=3D7186=3D=3D=0A=3D=3D7186=3D=3D Eve=
nts : Ir=0A=3D=3D7186=3D=3D Collected : 110292439=0A=3D=3D7186=3D=3D=0A=
=3D=3D7186=3D=3D I refs: 110,292,439=0AAborted=0A =0Athe program ra=
n perfectly without the profiling tool and generated the =0Aoutput files.=
=0A=0Acan anybody help me with a solution or a workaround plzzzz.=0A=0Adoes=
anyone know of other profiling tools that work well with gromacs?=0A=0Atha=
nk you in advance =0A=0Aregards =0Aganapathy senthilkumar =0A |
|
From: Nicholas N. <nj...@cs...> - 2006-05-08 23:44:22
|
On Mon, 8 May 2006, smiley glitter wrote: > Is there a way I can turn on > > VALGRIND_CHECK_WRITABLE > > client request for addrcheck in Valgrind 2.4.1 > version. > I get the following warning > > ==8635== Warning: Addrcheck: ignoring > `VALGRIND_CHECK_WRITABLE' request. > ==8635== To honour this request, rerun with > --tool=memcheck. That (or a similar request) isn't implemented for Addrcheck. It would be fairly straightforward to implement yourself. > I can't use memcheck as my application has a big test > base that can't be quickly tested with memcheck. You might have some luck with the current code in the SVN repository, where Memcheck runs noticeably faster than it used to, and uses much less memory. Nick |
|
From: smiley g. <smi...@ya...> - 2006-05-08 17:51:22
|
Is there a way I can turn on VALGRIND_CHECK_WRITABLE client request for addrcheck in Valgrind 2.4.1 version. I get the following warning ==8635== Warning: Addrcheck: ignoring `VALGRIND_CHECK_WRITABLE' request. ==8635== To honour this request, rerun with --tool=memcheck. I can't use memcheck as my application has a big test base that can't be quickly tested with memcheck. Some tips/hints to do it myself will be very helpful. Thanks in advance, Smile. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Julian S. <js...@ac...> - 2006-05-05 12:12:44
|
Which version of Valgrind is this with? And what CPU ? Can you make the shared lib available so we can look at what the debug info reader is doing? J On Friday 05 May 2006 08:25, Joachim Bauernberger wrote: > Dear list, > > we get the following assert when using valgrind: > > --24267-- Reading syms from > /utran/ngrncOmodel/lib/linux/debug/libcschnappi.so (0x1C491000) > valgrind: symtab.c:377 (vgModuleLocal_addCfiSI): Assertion 'cfisi->len > 0 > && cfisi->len < 2000000' failed > > could someone tell me how I can interpret this assert and whether it would > be safe to remove it? > > our program uses some shared libs and one of them is extremely big (200 > MB+). The assert happens during reading the symbols from this huge shared > lib. > > thanks, > joachim |
|
From: Joachim B. <joa...@gm...> - 2006-05-05 07:52:10
|
Dear list, we get the following assert when using valgrind: --24267-- Reading syms from /utran/ngrncOmodel/lib/linux/debug/libcschnappi.so (0x1C491000) valgrind: symtab.c:377 (vgModuleLocal_addCfiSI): Assertion 'cfisi->len > 0 && cfisi->len < 2000000' failed could someone tell me how I can interpret this assert and whether it would be safe to remove it? our program uses some shared libs and one of them is extremely big (200 MB+). The assert happens during reading the symbols from this huge shared lib. thanks, joachim |
|
From: Nicholas N. <nj...@cs...> - 2006-05-03 19:38:40
|
On Wed, 3 May 2006, Olly Betts wrote: >>> What version of valgrind should I use to have acess to the helgrind tool? >> >> 2.2.0 was the last version with a working Helgrind. >> >> This question seems to come up quite a bit - the answer's in the archives. > > Perhaps the error message which is given should mention that 2.2.0 > is the version you actually need if you want to use helgrind? The code in SVN gives this information, so it will be printed with 3.2.0 which will be out in the not-too-distant future. Nick |
|
From: Olly B. <ol...@su...> - 2006-05-03 17:00:15
|
On 2006-05-03, Paul Walker <pa...@bl...> wrote:
> On Wed, May 03, 2006 at 08:07:16AM -0700, Jose Silva wrote:
>
>> What version of valgrind should I use to have acess to the helgrind tool?
>
> 2.2.0 was the last version with a working Helgrind.
>
> This question seems to come up quite a bit - the answer's in the archives.
Perhaps the error message which is given should mention that 2.2.0
is the version you actually need if you want to use helgrind?
Cheers,
Olly
|
|
From: Paul W. <pa...@bl...> - 2006-05-03 16:32:19
|
On Wed, May 03, 2006 at 08:07:16AM -0700, Jose Silva wrote:
> What version of valgrind should I use to have acess to the helgrind tool?
2.2.0 was the last version with a working Helgrind.
This question seems to come up quite a bit - the answer's in the archives.
;-)
--
Paul
It's worse than that, it crashed, Jim.
|
|
From: Jose S. <joe...@gm...> - 2006-05-03 15:07:18
|
Hi I'm using vagrind-3.0.1 but when I try to use the helgrind tool I get th=
is:
Helgrind is currently not working, because:
(a) it is not yet ready to handle the Vex IR and the use with 64-bit
platforms introduced in Valgrind 3.0.0
(b) we need to get thread operation tracking working again after
the changes added in Valgrind 2.4.0
Sorry for the inconvenience. Let us know if this is a problem for you.
What version of valgrind should I use to have acess to the helgrind tool?
Regards,
Jose Silva
|
|
From: Igmar P. <mai...@jd...> - 2006-05-03 12:38:47
|
> > ==1614== Process terminating with default action of signal 11 (SIGSEGV) > > ==1614== Bad permissions for mapped region at address 0x4024BF4 > > ==1614== at 0x4024BF4: ??? > > Yup, as Igmar says, 0x4024BF4 is a rw- mapping of /lib/ld-2.2.5.so. > I have no idea why it would be trying to execute there. Hmm.. And a real pain to debug unfortunately. Someone with a bit more understanding how those perms get set might comment on this. Could be either a buggy libc, or the kernel doing something weird with the ELF mappings. Igmar |
|
From: David T. <twe...@ya...> - 2006-05-03 12:20:53
|
--- David Tweed <twe...@ya...> wrote:
> Is there any simple call I can put into my code to
> stop valgrind writing output for child branch of the
> fork()?
Just for completeness of the e-mail archives: once I
discovered that it's the exec family of functions that
stop valgrind for --trace-children=no, I realised that
rather than terminate the intermediate child with
_exit(0) I could terminate with
execl("/bin/true","/bin/true",(char *) NULL);
which suppresses valgrind's final output in that
branch. Ugly, but it's only debugging code :-) .
cheers, dave tweed
___________________________________________________________
Yahoo! Photos NEW, now offering a quality print service from just 7p a photo http://uk.photos.yahoo.com
|
|
From: Julian S. <js...@ac...> - 2006-05-03 12:00:42
|
> --1614:1:aspacem <<< SHOW_SEGMENTS: Memory layout at client startup (27 > segments, 3 segnames) > --1614:1:aspacem ( 0) /var/tmp/valgrind/ppc32-linux/memcheck > --1614:1:aspacem ( 1) /bin/busybox > --1614:1:aspacem ( 2) /lib/ld-2.2.5.so > --1614:1:aspacem 0: RSVN 0000000000-0003FFFFFF 64m ----- SmFixed > --1614:1:aspacem 1: file 0004000000-0004012FFF 77824 r-x-- d=0x1F02 > i=977784 o=0 (2) > --1614:1:aspacem 2: 0004013000-0004021FFF 61440 > --1614:1:aspacem 3: file 0004022000-0004025FFF 16384 rw--- d=0x1F02 > i=977784 o=73728 (2) > ==1614== Process terminating with default action of signal 11 (SIGSEGV) > ==1614== Bad permissions for mapped region at address 0x4024BF4 > ==1614== at 0x4024BF4: ??? Yup, as Igmar says, 0x4024BF4 is a rw- mapping of /lib/ld-2.2.5.so. I have no idea why it would be trying to execute there. J |