Thanks for your reply, with the information provided I was able to solve my
issue!
I inspected my code and as you said, there is a double unlocking of a
mutex. For reference for other people who might get this issue, I'll post
the problematic code below:
std::lock_guard<std::mutex> lock(mIncomingConnectionsMutex);
mIncomingConnections.push(clientConnection);
mIncomingConnectionsMutex.unlock();
Since std::lock_guard is RAII designed, there is no need to call unlock()
manually. It unlocks itself in the destructor anyway. I removed the third
line and it worked just fine.
Thanks for your help :)
On 10 September 2014 15:17, Mark Wielaard <m...@redhat.com> wrote:
> 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
