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
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(18) |
2
(6) |
|
3
(2) |
4
(2) |
5
(5) |
6
(12) |
7
(2) |
8
(1) |
9
(2) |
|
10
(6) |
11
(11) |
12
(12) |
13
(3) |
14
(3) |
15
(2) |
16
|
|
17
(2) |
18
(3) |
19
(43) |
20
(22) |
21
(10) |
22
(21) |
23
(5) |
|
24
|
25
(3) |
26
(12) |
27
(3) |
28
(14) |
29
(25) |
30
(5) |
|
31
(6) |
|
|
|
|
|
|
|
From: Christian P. <tr...@ge...> - 2005-07-22 19:49:15
|
On Friday 22 July 2005 10:50, Julian Seward wrote: > > Does someone know what exactly valgrind here is complaining about? > > Yes :-) > > You've probably hit one of the ultra-optimised strlen functions that > glibc provides. This is picking up chunks of string 8 bytes at a time > and doing some clever tricks with carry chain propagation so it doesn't > depend on the uninitialised bytes. Hence it's done an 8-byte read at > offset 16 of a malloc'd string of length 22. > > The memcheck in 2.4.0 doesn't complain about reading at partially > valid and partially invalid addresses, precisely to avoid reporting > this kind of error, but I thought that was sloppy and removed that > behaviour when rewriting it for Valgrind 3. > > It would help a lot if your /lib/ld-2.3.5.so had symbols, so that > V could possibly see it was calling strlen and reroute to a less > optimised version. Symbols would also make it possible to write > a decent suppression if Plan A failed. > > If you are a Gentoo insider .. please consider distributing non-stripped > /lib/ld-2.3.5.so as removing the symbols from it makes Valgrind's > life much more difficult. The same goes for glibc. That's not really funny, is it? It now have a version of glibc containing a= ll=20 symbols and now it doesn't show me all those warnings: $ valgrind -v --tool=3Dmemcheck --num-callers=3D32 .libs/lt-test=20 loading sandbox ### TLibrary(fileName=3Dlibsandbox.so) [...] sandbox loaded: libsandbox.so [...] =3D=3D12804=3D=3D =3D=3D12804=3D=3D ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 12 f= rom 4) =2D-12804-- =2D-12804-- supp: 3 index-not-intercepted-early-enough-HACK-1 =2D-12804-- supp: 1 strlen-not-intercepted-early-enough-HACK-4 =2D-12804-- supp: 1 strlen-not-intercepted-early-enough-HACK-3 =2D-12804-- supp: 7 dl_relocate_object =3D=3D12804=3D=3D malloc/free: in use at exit: 64 bytes in 2 blocks. =3D=3D12804=3D=3D malloc/free: 455 allocs, 453 frees, 105328 bytes allocate= d. [...] however, I get now some new messages I posted above. Are those "HACK"s somewhere documented? (they should be in the man-page e.g= =2E) Regards, Christian Parpart. =2D-=20 21:45:11 up 121 days, 10:52, 3 users, load average: 1.78, 2.48, 2.97 |
|
From: Bob D. <bd...@sr...> - 2005-07-22 19:25:31
|
Hello all, I've spent the last couple of hours trying to find the answer to this question in the archives, but I haven't found anything related to this for Fedora Core 3 and version 2.4 of valgrind. I'm a valgrind newbie, though, and I may not be looking for the right thing. Whenever I try to run valgrind, it dumps core (even on a "hello world" C ++ program) very soon after it is started... I built it from source with the -g cflag and tried to attach to it with gdb, using the --wait-for- gdb=yes feature, but I'm too ignorant to get that to do anything for me. I'm on a FC3 box. cat /proc/version tells me: Linux version 2.6.11-1.27_FC3smp (bhc...@po...) (gcc version 3.4.3 20050227 (Red Hat 3.4.3-22)) #1 SMP Tue May 17 20:43:11 EDT 2005 Here's what I'm seeing when valgrind dies on me... [prompt]$ /usr/local/bin/valgrind --tool=memcheck --leak-check=yes -- show-reachable=yes -v -v -v -v --run-libc-freeres=no ../project/mybinary ==14005== Memcheck, a memory error detector for x86-linux. ==14005== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==14005== Using valgrind-2.4.0, a program supervision framework for x86- linux. ==14005== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==14005== Valgrind library directory: /usr/local/lib/valgrind ==14005== Command line ==14005== ../feemaxprj/feemax ==14005== Startup, with flags: ==14005== --tool=memcheck ==14005== --leak-check=yes ==14005== --show-reachable=yes ==14005== -v ==14005== -v ==14005== -v ==14005== -v ==14005== --run-libc-freeres=no ==14005== Contents of /proc/version: ==14005== Linux version 2.6.11-1.27_FC3smp (bhc...@po...) (gcc version 3.4.3 20050227 (Red Hat 3.4.3-22)) #1 SMP Tue May 17 20:43:11 EDT 2005 ==14005== Reading syms from /home/bdusek/prj/feemax/feemaxprj/feemax (0x8048000) ==14005== Reading syms from /lib/ld-2.3.5.so (0x1B8E4000) ==14005== object doesn't have any debug info ==14005== Reading syms from /usr/local/lib/valgrind/stage2 (0xB0000000) ==14005== Reading syms from /lib/ld-2.3.5.so (0xB1000000) ==14005== object doesn't have any debug info ==14005== Reading syms from /usr/local/lib/valgrind/vgskin_memcheck.so (0xB7C4E000) ==14005== Reading syms from /lib/tls/libc-2.3.5.so (0xB7EAE000) ==14005== object doesn't have any debug info ==14005== Reading syms from /lib/libdl-2.3.5.so (0xB7FD9000) ==14005== object doesn't have any debug info ==14005== Reading suppressions file: /usr/local/lib/valgrind/default.supp --14005-- Translation Cache: using 8 sectors of 7260151 bytes each --14005-- Translation Table: 300007 total entries, max occupancy 240005 (80%) ==14005== --14005-- 0k bbs: tt 0, tc 0, after allocation of sector 0 (size 7260151) --14005-- 0k bbs: tt 0, tc 0, after commission of sector 0 at time 0 ==14005== Signal 11 (SIGSEGV) appears to have lost its siginfo; I can't go on. ==14005== This may be because one of your programs has consumed your ==14005== ration of siginfo structures. ==14005== ==14005== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==14005== at 0x1B8F001A: _dl_catch_error (in /lib/ld-2.3.5.so) ==14005== by 0x1B8E740C: dl_main (in /lib/ld-2.3.5.so) ==14005== by 0x1B8F37C4: _dl_sysdep_start (in /lib/ld-2.3.5.so) ==14005== by 0x1B8E53EF: _dl_start (in /lib/ld-2.3.5.so) ==14005== by 0x1B8E47C6: (within /lib/ld-2.3.5.so) Can anyone point me in the right direction? |
|
From: Christian P. <tr...@ge...> - 2005-07-22 18:53:23
|
On Friday 22 July 2005 20:47, Nicholas Nethercote wrote: > On Fri, 22 Jul 2005, Christian Parpart wrote: > >> It's mapping it to stop anything else being given that part of the > >> address space - it is how valgrind controls where the OS puts stuff. > > > > While using it now some more times, I must unfortunately see, that it > > becomes more and more unsuable to me. Those idling times I have to wait > > until valgrind actually starts and actually exits decrease my > > productivity :( > > > > Is there any way to walk around this? > > Nobody else seems to be having this problem. What kernel are you using? Oh well..... poor me: Linux battousai 2.6.12-gentoo-r2 #1 Thu Jun 30 15:45:25 CEST 2005 x86_64 AM= D=20 Athlon(tm) 64 Processor 3500+ AuthenticAMD GNU/Linux I could upgrade to gentoo-r6, but I should have closed lots of windows in m= y X=20 before (which takes hell - I stopped counting them); But I shall give it a try anyway I guess :( I hate rebooting, Christian Parpart. =2D-=20 20:51:00 up 121 days, 9:58, 2 users, load average: 4.29, 3.39, 3.08 |
|
From: Nicholas N. <nj...@cs...> - 2005-07-22 18:47:48
|
On Fri, 22 Jul 2005, Christian Parpart wrote: >> It's mapping it to stop anything else being given that part of the >> address space - it is how valgrind controls where the OS puts stuff. > > While using it now some more times, I must unfortunately see, that it becomes > more and more unsuable to me. Those idling times I have to wait until > valgrind actually starts and actually exits decrease my productivity :( > > Is there any way to walk around this? Nobody else seems to be having this problem. What kernel are you using? N |
|
From: Christian P. <tr...@ge...> - 2005-07-22 18:32:31
|
On Wednesday 20 July 2005 16:54, Tom Hughes wrote: > In message <200...@ge...> > > Christian Parpart <tr...@ge...> wrote: > > On Wednesday 20 July 2005 15:39, Nicholas Nethercote wrote: > >> The mmap and munmap calls are very big -- 61680GB and 69390GB > >> respectively. The fact that it happens before the usage message shows > >> this is happening very early. I guess these mmap/munmap calls are from > >> the start-up padding, but then the question is why isn't this causing > >> problems on other AMD64 systems? > > > > I'm having 2GB RAM, and 1GB swap. maybe this matters? > > Besides, why the hell is valgrind m[un]mapping such a huge space (I even > > haven't that much RAM et al) > > It's mapping it to stop anything else being given that part of the > address space - it is how valgrind controls where the OS puts stuff. While using it now some more times, I must unfortunately see, that it becom= es=20 more and more unsuable to me. Those idling times I have to wait until=20 valgrind actually starts and actually exits decrease my productivity :( Is there any way to walk around this? Regards, Christian Parpart. =2D-=20 20:31:10 up 121 days, 9:38, 2 users, load average: 1.34, 2.22, 2.62 |
|
From: Christian P. <tr...@ge...> - 2005-07-22 18:29:41
|
On Friday 22 July 2005 10:50, Julian Seward wrote: > The memcheck in 2.4.0 doesn't complain about reading at partially > valid and partially invalid addresses, precisely to avoid reporting > this kind of error, but I thought that was sloppy and removed that > behaviour when rewriting it for Valgrind 3. So, in the end, is this a bug in glibc then? Which would mean for me to use= an=20 alternative way to count null terminated strings. Or should ignore this=20 message and wait until valgrind 3 will suppress those messages? > It would help a lot if your /lib/ld-2.3.5.so had symbols, so that > V could possibly see it was calling strlen and reroute to a less > optimised version. That's the easiest part. gimme some time to re-emerge it ;-) > Symbols would also make it possible to write=20 > a decent suppression if Plan A failed. > > If you are a Gentoo insider .. please consider distributing non-stripped > /lib/ld-2.3.5.so as removing the symbols from it makes Valgrind's > life much more difficult. The same goes for glibc. glibc is not my special subject though, but I can talk to those who are ;) Regards, Christian Parpart. =2D-=20 20:25:39 up 121 days, 9:33, 2 users, load average: 1.66, 2.23, 2.76 |
|
From: Julian S. <js...@ac...> - 2005-07-22 18:10:31
|
> Does someone know what exactly valgrind here is complaining about? Yes :-) You've probably hit one of the ultra-optimised strlen functions that glibc provides. This is picking up chunks of string 8 bytes at a time and doing some clever tricks with carry chain propagation so it doesn't depend on the uninitialised bytes. Hence it's done an 8-byte read at offset 16 of a malloc'd string of length 22. The memcheck in 2.4.0 doesn't complain about reading at partially valid and partially invalid addresses, precisely to avoid reporting this kind of error, but I thought that was sloppy and removed that behaviour when rewriting it for Valgrind 3. It would help a lot if your /lib/ld-2.3.5.so had symbols, so that V could possibly see it was calling strlen and reroute to a less optimised version. Symbols would also make it possible to write a decent suppression if Plan A failed. If you are a Gentoo insider .. please consider distributing non-stripped /lib/ld-2.3.5.so as removing the symbols from it makes Valgrind's life much more difficult. The same goes for glibc. J |
|
From: Christian P. <tr...@ge...> - 2005-07-22 18:06:14
|
On Friday 22 July 2005 12:44, Dennis Lubert wrote: > Hi, > > Hm, I really dont understand the problem with the current format. Valgrind > displays the occurence and failure (in this case an invalid read)=20 "invalid read" shall be maybe replaced by "invalid read of %d bytes outside= =20 reserved block" or so. However, these messages shall -for sure- be somehow simplified, here I agre= e=20 with bartoschek. Regards, Christian Parpart. =2D-=20 20:03:57 up 121 days, 9:11, 2 users, load average: 2.06, 2.32, 4.04 |
|
From: Yeshurun, M. <mei...@in...> - 2005-07-22 15:25:17
|
Thanks, it worked better than before, but then I got, like Cristoph:
VG_(get_memory_from_mmap): newSuperblock's request for 1048576 bytes
failed.
VG_(get_memory_from_mmap): 224186560 bytes already allocated.
Sorry. You could try using a tool that uses less memory;
eg. addrcheck instead of memcheck.
Does anyone have any suggestions?
Thanks,
Meir
-----Original Message-----
From: val...@li...
[mailto:val...@li...] On Behalf Of Tom
Hughes
Sent: Friday, July 22, 2005 5:23 PM
To: val...@li...
Subject: Re: [Valgrind-users] AMD64 and memory
In message
<942...@ha...>
Meir Yeshurun <mei...@in...> wrote:
> I got
>
> relocation can not be used when making a shared object; recompile with
> -fPIC
>
> What should I do?
You probably need to specify EXTRA_CFLAGS=3D"-fpie" when you are=20
building vex or vex won't be position independent and won't be able
to be linked into valgrind.
Tom
--=20
Tom Hughes (to...@co...)
http://www.compton.nu/
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. =
http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Tom H. <to...@co...> - 2005-07-22 14:23:05
|
In message <942...@ha...>
Meir Yeshurun <mei...@in...> wrote:
> I got
>
> relocation can not be used when making a shared object; recompile with
> -fPIC
>
> What should I do?
You probably need to specify EXTRA_CFLAGS="-fpie" when you are
building vex or vex won't be position independent and won't be able
to be linked into valgrind.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Yeshurun, M. <mei...@in...> - 2005-07-22 14:15:31
|
I got
relocation can not be used when making a shared object; recompile with
-fPIC
What should I do?
Thanks,
Meir
-----Original Message-----
From: val...@li...
[mailto:val...@li...] On Behalf Of Tom
Hughes
Sent: Friday, July 22, 2005 4:40 PM
To: val...@li...
Subject: Re: [Valgrind-users] AMD64 and memory
In message
<942...@ha...>
Meir Yeshurun <mei...@in...> wrote:
> What does this --enable-pie flag supposed to do? I tried it, Valgrind
> doen't even accept this flag.
It's an option to configure when you build valgrind. It causes it to
be built as a position independent executable so that it can be loaded
anywhere in the address space instead of at a fixed position.
Tom
--=20
Tom Hughes (to...@co...)
http://www.compton.nu/
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. =
http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Tom H. <to...@co...> - 2005-07-22 13:40:04
|
In message <942...@ha...>
Meir Yeshurun <mei...@in...> wrote:
> What does this --enable-pie flag supposed to do? I tried it, Valgrind
> doen't even accept this flag.
It's an option to configure when you build valgrind. It causes it to
be built as a position independent executable so that it can be loaded
anywhere in the address space instead of at a fixed position.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Yeshurun, M. <mei...@in...> - 2005-07-22 13:22:48
|
Hi, What does this --enable-pie flag supposed to do? I tried it, Valgrind doen't even accept this flag. Thanks, Meir -----Original Message----- From: val...@li... [mailto:val...@li...] On Behalf Of Christoph Bartoschek Sent: Thursday, July 21, 2005 3:33 PM To: val...@li... Subject: [Valgrind-users] AMD64 and memory Hi, Someone mentioned that with --enable-pie one can use more memory on AMD64=20 than 1.5GB. Is this correct? However I tried this and it goes further thant without --enable-pie and uses=20 3.5GB when it stops with the following message: coregrind/m_aspacemgr/aspacemgr.c: VG_N_SEGNAMES is too small: increase it and rebuild Valgrind. coregrind/m_aspacemgr/aspacemgr.c: giving up now. What would be a reasonable value for this constant? Should I also increase the=20 other constants in this file? Christoph ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. = http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Dennis L. <pla...@in...> - 2005-07-22 10:44:41
|
Hi, Hm, I really dont understand the problem with the current format. Valgrind displays the occurence and failure (in this case an invalid read) and after that the memory location where it was allocated and where the access was (or just the address if the address isnt mallocd or stacked). Thats the format for all valgrind messages. Theyre both clearly in one block, indicated through indentation and blank lines between them. For those to whom this format isnt intuitive, its clearly documented in the manual.html... greets Dennis At 10:02 22.07.2005, Christoph Bartoschek wrote: > > ==23198== Invalid read of size 8 > > ==23198== Address 0x140EF0FCE020 is 16 bytes inside a block of size 22 >alloc'd > >Everyone I showed valgrind had a problem understanding this error message and >especially the two tracebacks. Maybe it is possible to simplify this >message. My suggestion would be: > > >Invalid read of size 8 starting at address 0x140EF0FCE020 ><Traceback1> > >Address 0x140EF0FCE020 is 16 bytes inside a block of size 22 ><Traceback2> > >here the address is the link between both messages. One could think of >additional hints for the user. However this goes at the cost of brevity. > >Christoph Bartoschek Carpe quod tibi datum est |
|
From: Christoph B. <bar...@or...> - 2005-07-22 08:02:21
|
> ==23198== Invalid read of size 8 > ==23198== Address 0x140EF0FCE020 is 16 bytes inside a block of size 22 alloc'd Everyone I showed valgrind had a problem understanding this error message and especially the two tracebacks. Maybe it is possible to simplify this message. My suggestion would be: Invalid read of size 8 starting at address 0x140EF0FCE020 <Traceback1> Address 0x140EF0FCE020 is 16 bytes inside a block of size 22 <Traceback2> here the address is the link between both messages. One could think of additional hints for the user. However this goes at the cost of brevity. Christoph Bartoschek |
|
From: Nicholas N. <nj...@cs...> - 2005-07-22 02:50:44
|
On Fri, 22 Jul 2005, Christian Parpart wrote: > ==23198== Invalid read of size 8 > ==23198== Address 0x140EF0FCE020 is 16 bytes inside a block of size 22 alloc'd > > However, "Invalid read of size 8" and "Address XXXX is 16 bytes inside a > block of size 22 alloc'd" are two error messages I can't really bring > together (nor really understand alone); Do they belong together anyway? You have a heap block 22 bytes long. You are reading 8 bytes of it, beginning at byte 16. 16 + 8 is greater than 22, so you're reading past the end of the heap block. N |
|
From: Nicholas N. <nj...@cs...> - 2005-07-22 02:41:28
|
On Thu, 21 Jul 2005, Allin Cottrell wrote: >>> Has anyone else seen this with 2.4.0? Does anyone have a suggestion >>> on how I could produce a more useful report? >> >> configure with --disable-pie > > Thanks, that did it. Could this be added to the FAQ? (Or perhaps the iFAQ -- > infrequently asked questions?) It'll be turned off by default in the next release. N |
|
From: Christian P. <tr...@ge...> - 2005-07-22 01:54:09
|
Hi, The following is partly the output of my test code: =3D=3D23198=3D=3D Invalid read of size 8 =3D=3D23198=3D=3D at 0x140EEDB10743: (within /lib/ld-2.3.5.so) =3D=3D23198=3D=3D by 0x140EEDB06871: (within /lib/ld-2.3.5.so) =3D=3D23198=3D=3D by 0x140EF0E709CB: (within /lib/libc-2.3.5.so) =3D=3D23198=3D=3D by 0x140EEDB0B40F: (within /lib/ld-2.3.5.so) =3D=3D23198=3D=3D by 0x140EF0E71589: _dl_open (in /lib/libc-2.3.5.so) =3D=3D23198=3D=3D by 0x140EF02740B3: (within /lib/libdl-2.3.5.so) =3D=3D23198=3D=3D by 0x140EEDB0B40F: (within /lib/ld-2.3.5.so) =3D=3D23198=3D=3D by 0x140EF02745B1: (within /lib/libdl-2.3.5.so) =3D=3D23198=3D=3D by 0x140EF02740F1: dlopen (in /lib/libdl-2.3.5.so) =3D=3D23198=3D=3D by 0x140EEE899E67: System::Runtime::TLibrary::TLibrary= (System::TStringBase<char> const&, System::TStringBase<char> const&) (TLibr= ary.cpp:41) =3D=3D23198=3D=3D by 0x140EEE89AE4A: System::Runtime::TLibraryMgr::loadL= ibrary(System::TStringBase<char> const&) (TLibraryMgr.cpp:94) =3D=3D23198=3D=3D by 0x410931: main (yacsd.cpp:348) =3D=3D23198=3D=3D Address 0x140EF0FCE020 is 16 bytes inside a block of siz= e 22 alloc'd =3D=3D23198=3D=3D at 0x140EEDD1D3A0: operator new(unsigned long) (vg_rep= lace_malloc.c:168) =3D=3D23198=3D=3D by 0x140EEE3D243D: System::TStringRep<char>::create(un= signed) (String.cpp:82) =3D=3D23198=3D=3D by 0x140EEE3D1721: System::TStringBase<char>::TStringB= ase(char const*) (String.cpp:345) =3D=3D23198=3D=3D by 0x410924: main (yacsd.cpp:347) However, "Invalid read of size 8" and "Address XXXX is 16 bytes inside a bl= ock of size 22 alloc'd"=20 are two error messages I can't really bring together (nor really understand= alone); Do they belong together anyway? And, while trying to find out what exactly goes wrong in my code, I shall f= irst clarify those messages (especially the second one): The test application is a simple main() that just instanciates a C++ class = for library loading=20 and actually loads one - so, it's a two-liner. And I really can't find what= I am doing wrong there. The String class is really very heavily in use, but valgrind seems to compl= ain only when I am loading a library via TLibraryMgr.loadLibrary(); Does someone know what exactly valgrind here is complaining about? Thanks in advance, Christian Parpart. =2D-=20 03:41:58 up 120 days, 16:49, 0 users, load average: 4.15, 4.52, 4.30 |
|
From: Allin C. <cot...@wf...> - 2005-07-22 00:20:35
|
On Tue, 19 Jul 2005, Dirk Mueller wrote: > On Tuesday 19 July 2005 14:04, Allin Cottrell wrote: > >> Has anyone else seen this with 2.4.0? Does anyone have a suggestion >> on how I could produce a more useful report? > > configure with --disable-pie Thanks, that did it. Could this be added to the FAQ? (Or perhaps the iFAQ -- infrequently asked questions?) Allin Cottrell |
|
From: <Woe...@on...> - 2005-07-21 20:57:57
|
On Saturday 02 July 2005 17:06, Nicholas Nethercote wrote: > On Sat, 2 Jul 2005, Andr=E9 W=F6bbeking wrote: > > GNU ld version 2.16 Debian GNU/Linux > > > > glibc-2.3.5-1 (after 2.3.2 failed) > > > > Is there a way to dynamic link valgrind or do you've other tips? > > That looks more like a problem with your system libraries than a > problem with Valgrind. Do you have access to another machine you can > try it on? =46YI, it works with glibc-2.3.5-2 from Debian experimental. Cheers, Andr=E9 |
|
From: Dennis L. <pla...@in...> - 2005-07-21 20:52:08
|
At 22:16 21.07.2005, Fred Smith wrote: >I think the answer is NO, but let me ask anyway=85. > >Has anyone made valgrind work on Cygwin? No, valgrind is currently supporting Linux Operating System only (with the= =20 exception of some patched ports to unix-like operating systems). Windows is= =20 a whole different world. > >Thanks! > >Fred This is a block of unuseful text for wasting bandwith. This is a block of=20 unuseful text for wasting bandwith. This is a block of unuseful text for=20 wasting bandwith. This is a block of unuseful text for wasting bandwith. Carpe quod tibi datum est=20 |
|
From: Fred S. <fr...@co...> - 2005-07-21 20:16:11
|
I think the answer is NO, but let me ask anyway....=0D =0D Has anyone made valgrind work on Cygwin? =0D Thanks! =0D Fred This email and any files transmitted with it are confidential and intended= solely for the use of the individual or entity to which they are= addressed. If you have received this email in error, please notify the= system manager. Please note that any views or opinions presented in this= email are solely those of the author and do not necessarily represent= those of the company. Finally, the recipient should check this email and= any attachments for the presence of viruses. The company accepts no= liability for any damage caused by any virus transmitted by this email. |
|
From: Fred S. <fr...@co...> - 2005-07-21 20:15:15
|
I'm working on a multi-threaded program on Linux, using valgrind 2.4. =0D When I run it like this: =0D valgrind --tool=3Dmemcheck --gen-suppressions=3Dyes --suppressions=3D./my.suppressions --error-limit=3Dno --num-callers=3D50 --track-fds=3Dyes --leak-check=3Dyes --workaround-gcc296-bugs=3Dyes program_name program_args =0D it prints the question about generating suppressions BUT DOES NOT PAUSE FOR ME TO ANSWER IT. It keeps right on spewing errors. =0D What am I doing wrong? =0D Thanks! =0D Fred This email and any files transmitted with it are confidential and intended= solely for the use of the individual or entity to which they are= addressed. If you have received this email in error, please notify the= system manager. Please note that any views or opinions presented in this= email are solely those of the author and do not necessarily represent= those of the company. Finally, the recipient should check this email and= any attachments for the presence of viruses. The company accepts no= liability for any damage caused by any virus transmitted by this email. |
|
From: Christoph B. <bar...@or...> - 2005-07-21 14:38:23
|
Am Donnerstag 21 Juli 2005 14:39 schrieb Julian Seward: > > coregrind/m_aspacemgr/aspacemgr.c: > > VG_N_SEGNAMES is too small: increase it and rebuild Valgrind. > > coregrind/m_aspacemgr/aspacemgr.c: > > giving up now. > > > > What would be a reasonable value for this constant? Should I also > > increase the other constants in this file? > > Just keep doubling it until it works, then let me know what you had > to set it to. 500 works, but I did not get to the end of loaded libraries because valgrind stopped: VG_(get_memory_from_mmap): newSuperblock's request for 2052096 bytes failed. VG_(get_memory_from_mmap): 242441728 bytes already allocated. Sorry. You could try using a tool that uses less memory; eg. addrcheck instead of memcheck. Christoph |
|
From: Nicholas N. <nj...@cs...> - 2005-07-21 14:11:16
|
On Wed, 20 Jul 2005, Dennis Lubert wrote: > after looking how to tell valgrind about own memory allocators or mempools, I > found that it looks like I need to insert client requests. Now this is not > always possible, since it needs recompiling and change (maybe not available) > source code. > Now my Idea (and thus the question if this is possible) was to use some > function interception stuff to tell valgrind that those functions allocate > memory? Maybe even with some config files so neither recompilation of > valgrind nor the executable is needed ? It would be nice, but I don't think we have sufficiently powerful function interception/wrapping machinery to do this. N |