[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190917143510.GX9017@brightrain.aerifal.cx>
Date: Tue, 17 Sep 2019 10:35:10 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Bug report, concurrency issue on exception with gcc 8.3.0
On Tue, Sep 17, 2019 at 10:02:27AM -0400, Rich Felker wrote:
> On Tue, Sep 17, 2019 at 03:44:22PM +0200, Max Neunhoeffer wrote:
> > Hello,
> >
> > I am experiencing problems when linking a large multithreaded C++ application
> > statically against libmusl. I am using Alpine Linux 3.10.1 and gcc 8.3.0
> > on X86_64. That is, I am using libmusl 1.1.22-r3 (Alpine Linux versioning)
> > and gcc 8.3.0-r0.
> >
> > Before going into details, here is an overview:
> >
> > 1. libgcc does not detect correctly that the application is multithreaded,
> > since `pthread_cancel` is not linked into the executable.
> > As a consequence, the lazy initialization of data structures for stack
> > unwinding (FDE tables) is executed without protection of a mutex.
> > Therefore, if the very first exception in the program happens to be
> > thrown in two threads concurrently, the data structures can be corrupted,
> > resulting in a busy loop after `main()` is finished.
> > 2. If I make sure that I explicitly link in `pthread_cancel` this problem
> > is (almost certainly) gone, however, in certain scenarios this leads
> > to a crash when the first exception is thrown.
> >
> > I had first reported this problem to gcc as a bug against libgcc, but the
> > gcc team denies responsibility, see
> > [this bug report](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91737).
>
> This is a gcc bug and needs to be fixed in libgcc.
I've updated the gcc tracker with more info, but I seem to lack the
ability to reopen the bug myself.
To add some more context, using weak references to determine if a
library is linked is a dynamic-linking-centric hack and is not
compatible with static linking. GCC has historically done this for
glibc and other systems where libpthread was a separate library to
avoid pulling in a dependency on it, but it's always been broken on
glibc with static linking too. Various distros worked around this with
horrible hacks as described in Andrew Pinski's reply to your bug
report, using binutils tricks to move the whole libpthread.a into a
single .o file so that if any of it gets linked it all gets linked.
It's possibly upstream glibc adopted this at some point; I'm not sure.
But they're in the process of moving the mutex functions to libc
instead of libpthread (and maybe even getting rid of libpthread like
musl does), so GCC's hacks here won't even provide any benefit with
future glibc versions.
In any case, this kind of pushback against fixes for clear bugs used
to be expected, but things have gotten a lot better with musl being
more mainstream nowadays. I think the issue will get resolved quickly
once a few more GCC developers look at it. It was actually just
reopened while I was writing this email.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
