|
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: 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: 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: 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: 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: David F. <dav...@bl...> - 2005-07-23 16:25:44
|
how about" "read of 8 bytes at 0x5678 goes past allocation boundary" "allocation is 22 bytes long starting at 0x1234" -david Christian Parpart wrote: > 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) >> > > "invalid read" shall be maybe replaced by "invalid read of %d bytes outside > reserved block" or so. > > However, these messages shall -for sure- be somehow simplified, here I agree > with bartoschek. > > Regards, > Christian Parpart. > > |
|
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: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: 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: David F. <dav...@bl...> - 2005-07-23 16:29:26
|
Gentoo users can make non-stripped glibc/ld by using: FEATURES=nostrip emerge <package> Julian Seward wrote: > [...] > > 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. > |