Re: [Valgrind-users] Conditional jump or move depends on uninitialised value and its reason

[John R. <jr...@bi...>]

> I'm using Arch Linux and found old bug about strlen and SSE instructions among other thing. Also there was some posts about stripped libc and I have:
> $ file /lib/libc-2.14.1.so
> /lib/libc-2.14.1.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), BuildID[sha1]=0x84c4a5b908da76082cff58f393bee5d9c15d9684, for GNU/Linux 2.6.27, stripped
> 
> Does that have something to do with puts() error?

Yes!  *DO NOT USE* Arch Linux with valgrind!  Arch Linux has blundered
by stripping glibc and not supplying the debug info in some other way
(such as in a corresponding glibc-debuginfo package, like Fedora Project.)
This grave mistake will make life miserable for users of memcheck.

Refer to the initial post to [Valgrind-users] by Dominic Monroe with subject
"Valgrind 3.7 + GLibc 1.4.1" [sic] about three weeks ago on 11/25/2011;
any my reply two days later.  Invoke valgrind with the additional
command-line parameter "--db-attach=yes" and look at the instructions
which surround the error [done here with valgrind 3.7.0 on i686]:

==760== Conditional jump or move depends on uninitialised value(s)
==760==    at 0x40AD029: ??? (in /lib/libc-2.14.1.so)
==760==    by 0x409597D: fputs (in /lib/libc-2.14.1.so)
==760==    by 0x804850F: main (main.c:11)

==760== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y

(gdb) x/12i $pc-0x18
   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   ###
   0x40ad028:	dec    %edx
=> 0x40ad029:	jae    0x40ad069
   0x40ad02b:	xor    %ecx,%edx
   0x40ad02d:	and    $0x1010100,%edx   ###
   0x40ad033:	jne    0x40ad069

Notice those constant values 0x1010100 and 0xfefefeff.  Those are
the hallmarks of optimized code which scans for the terminating
'\0' character in a string, inspecting 4 bytes (one word) at a time.
Memcheck does not understand such code, so memcheck replaces
known subroutines with its own equivalent code.  If the debug info
has been stripped, then several such subroutines become invisible,
memcheck does not replace them, and memcheck gets lost.

Also notice that gdb prints hex addresses such as "0x40ad029"
instead of a symbol name plus small offset.  This indicates that
gdb cannot find debug information for those instructions
(because Arch Linux stripped it, and did not put it somewhere else
where it is accessible to gdb.)

*DO NOT USE* Arch Linux with memcheck!

--