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 ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
