On 11/26/2011 03:37 AM, Dominic Monroe wrote:
> When setting the locale to C, there is no issue. [snip]
With the current Arch Linux default package glibc-2.14-1 [x86], then memcheck
does not complain for any of the three locales C, en_US.utf-8, and ru_RU.utf-8.
After "pacman --sync glibc" updates to glibc-2.14.1-1, then locale C
still is OK, but both en_US.utf-8 and ru_RU.utf-8 draw complaints.
Invoking valgrind with the additional parameter "--db-attach=yes"
and investigating:
==718== Invalid read of size 4
==718== at 0x40AD01B: ??? (in /lib/libc-2.14.1.so)
==718== by 0x405B1E8: ??? (in /lib/libc-2.14.1.so)
==718== by 0x405AD33: setlocale (in /lib/libc-2.14.1.so)
==718== by 0x8048400: main (setlocale.c:6)
==718== Address 0x41b402c is 4 bytes inside a block of size 5 alloc'd
==718== at 0x402A018: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==718== by 0x406242B: ??? (in /lib/libc-2.14.1.so)
==718== by 0x405C4A4: ??? (in /lib/libc-2.14.1.so)
==718== by 0x405B1E8: ??? (in /lib/libc-2.14.1.so)
==718== by 0x405AD33: setlocale (in /lib/libc-2.14.1.so)
==718== by 0x8048400: main (setlocale.c:6)
==718==
==718==
==718== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y
==718== starting debugger with cmd: /usr/bin/gdb -nw /proc/720/fd/1024 720
[snip]
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
0x040ad01b in ?? () from /lib/libc.so.6
(gdb) x/12i 0x40ad01b-0x18 # Look at instructions near the point of error.
0x40ad003: add $0x4,%eax
0x40ad006: sub %ecx,%edx
0x40ad008: add $0xfefefeff,%ecx ###
0x40ad00e: dec %edx
0x40ad00f: jae 0x40ad069
0x40ad011: xor %ecx,%edx
0x40ad013: and $0x1010100,%edx ###
0x40ad019: jne 0x40ad069
=> 0x40ad01b: mov (%eax),%ecx
0x40ad01d: add $0x4,%eax
0x40ad020: sub %ecx,%edx
0x40ad022: add $0xfefefeff,%ecx ###
Note the constants 0x01010100 and 0xfefefeff in the marked lines "###".
Those constants strongly hint at code which checks for '\0', four bytes
at a time. Valgrind does not understand such code, so usually valgrind
redirects any calls to an equivalent subroutine which valgrind does
understand; for example:
--718-- REDIR: 0x40af860 (strchrnul) redirected to 0x402cd90 (strchrnul)
Note that valgrind could find no subroutine name, only "???":
==718== at 0x40AD01B: ??? (in /lib/libc-2.14.1.so)
and that gdb detected "no debugging symbols found" in libc.so.6 and
ld-linux.so.2. As a result, gdb does not display a symbolic name for
addresses such as 0x40ad01b.
What has happened is that valgrind did not redirect some super-optimized
subroutine that checks for '\0' in a character string. The reason why
valgrind did not detect the code is that Arch Linux stripped all the debug
information from glibc, and did not provide the debug info in an alternate
form, such as a glibc-debuginfo package [see Fedora Linux.]
The workaround is to construct and use valgrind suppression files for these
complaints. The fix is for Arch Linux not to strip the debug info, or for
Arch Linux to provide [and for you to install] a corresponding package
glibc-debuginfo which contains the matching debug information (all
subroutine names, line numbers, etc.)
--
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
