Re: [Valgrind-users] Possible bug in valgrind?

[Mark W. <mj...@re...>]

On Wed, 2014-09-10 at 12:27 +0200, Tobias Widlund wrote:
> Thanks for the reply, I did download and build the valgrind version you
> linked and the illegal instruction error went away, but instead I am
> getting a segfault on the same place, as seen:

OK, that is somewhat expected. valgrind 3.10.0[BETA] now knows about the
xend instruction, but sees it is used outside an transaction and so
generates a SIGSEGV to indicate bad usage of xend (instead of a SIGILL
to indicate it doesn't understand the instruction at all).

> tobbe@archosaurus ~/projects/blocks (git)-[master] % valgrind ./bin/blocks
> [...]
> ==7731== Process terminating with default action of signal 11 (SIGSEGV):
> dumping core
> ==7731==  General Protection Fault
> ==7731==    at 0x5145EBB: __lll_unlock_elision (in /usr/lib/
> libpthread-2.19.so)
> ==7731==    by 0x441D31:
> LocalClientConnectionListener::createClientConnection(LocalServerClientBridge*)
> (in /home/tobbe/projects/blocks/bin/blocks)
> ==7731==    by 0x4432D6: BlocksApplication::setupSinglePlayer() (in
> /home/tobbe/projects/blocks/bin/blocks)
> ==7731==    by 0x58ABA2E: fea::Application::run(int, char**) (in
> /usr/local/lib/libfea-structure.so)
> ==7731==    by 0x4497F5: main (in /home/tobbe/projects/blocks/bin/blocks)
> [...]
> [5]    7731 segmentation fault  valgrind ./bin/blocks
> valgrind ./bin/blocks  7.64s user 0.11s system 99% cpu 7.760 total
> 
> This segfault does not happen without valgrind. Any ideas?

So the difference might be that your native cpu doesn't support TSX, but
valgrind is emulating it anyway and sets the cpuid field that glibc
picks up and tries to use (valgrind -v might show you, grep for "Arch
and hwcaps"). This is kind of a bug in valgrind, it should manage the
cpuid bits a bit more intelligently
(https://bugs.kde.org/show_bug.cgi?id=324882).

But that might still mean there is a bug in either your program or
glibc. What seems to be happening is that a mutex is unlocked in your
code that isn't locked in the first place (glibc with TSX lock elision
is a bit aggressive and just xends a transaction that isn't there). So I
would first look at createClientConnection() and see if there is any
suspicious unlocking going on. Otherwise it might also be this glibc
bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16657
"Lock elision breaks pthread_mutex_destroy".

Cheers,

Mark