Philippe Waroquiers 99c6a6d880 Fix incorrect (or infinite loop) unwind on RHEL7 x86 32 bits. ...

On RHEL7 x86 32 bits, Valgrind unwinder cannot properly unwind
the stack just after a thread creation : the unwinder always retrieves
the same pc/sp/bp.
See below for an example.
This has as consequences that some stack traces are bigger than
needed (i.e. they always fill up the ips array). If
--merge-recursive-frames is given, then the unwinder enters in an
infinite loop (as identical frames will be merged, and the ips array
will never be filled in).
Thi patch adds an additional exit condition : after unwinding
a frame, if the previous sp is >= new sp, then unwinding stops.
Patch has been tested on debian 8/x86, RHEL7/x86.



   0x0417db67 <+55>:    mov    0x18(%esp),%ebx
   0x0417db6b <+59>:    mov    0x28(%esp),%edi
   0x0417db6f <+63>:    mov    $0x78,%eax
   0x0417db74 <+68>:    mov    %ebx,(%ecx)
   0x0417db76 <+70>:    int    $0x80
=> 0x0417db78 <+72>:    pop    %edi
   0x0417db79 <+73>:    pop    %esi
   0x0417db7a <+74>:    pop    %ebx
   0x0417db7b <+75>:    test   %eax,%eax

Valgrind stacktrace gives:
==21261==    at 0x417DB78: clone (clone.S:110)
==21261==    by 0x424702F: ???
==21261==    by 0x424702F: ???
==21261==    by 0x424702F: ???
==21261==    by 0x424702F: ???
==21261==    by 0x424702F: ???
==21261==    by 0x424702F: ???
==21261==    by 0x424702F: ???
...
(till the array of ips is full)

while gdb stacktrace gives:
(gdb) bt
#0  clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:110
#1  0x00000000 in ?? ()
(gdb) p $pc
$2 = (void (*)()) 0x417db78 <clone+72>
(gdb)


With the fix, valgrind gives:
==21261==    at 0x417DB78: clone (clone.S:110)
==21261==    by 0x424702F: ???
which looks more reasonable.




git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15729

2015-11-18 20:56:55 +00:00

64 KiB

Raw Blame History

View Raw