From: Max Neunhoeffer <max@arangodb.com>
To: musl@lists.openwall.com
Subject: Re: Bug report, concurrency issue on exception with gcc 8.3.0
Date: Wed, 18 Sep 2019 14:45:51 +0200 [thread overview]
Message-ID: <20190918124551.lsibbaouordfrddv@zen.arangodb.com> (raw)
In-Reply-To: <20190918092149.GT22009@port70.net>
Hello,
thank you very much for the explanation. This gives me a temporary way
to fix up our application until the bug has been fixed.
Cheers,
Max.
On 19/09/18 11:21, Szabolcs Nagy wrote:
> * Max Neunhoeffer <max@arangodb.com> [2019-09-18 09:19:31 +0200]:
> > thanks for the quick response and for lobbying with the gcc folks!
> >
> > Did you see the second example program in the original bug report? This
> > seems to indicate that there might be an additional problem, since when
> > I explicitly use `pthread_cancel` (thereby circumventing the detection
> > problem), I get a crash when the first exception is thrown.
>
> pthread_cancel does not solve the detection problem.
>
> reference to pthread_cancel only helps with dynamic linking.
> in case of static linking you have to explicitly add (strong)
> reference to symbols that libgcc_eh.a uses:
>
> pthread_cancel
> pthread_getspecific
> pthread_key_create
> pthread_mutex_lock
> pthread_mutex_unlock
> pthread_once
> pthread_setspecific
>
> where pthread_cancel is only needed to make libgcc_eh.a call the
> thread functions (but those are all weakrefs so will just be 0
> at runtime unless there are other strong references to them).
>
> >
> > Do you think this is a libgcc problem, too? Should I report this to the
> > gcc bug tracker as well?
> >
> > Cheers,
> > Max.
> >
> > On 19/09/17 10:35, Rich Felker wrote:
> > > 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
next prev parent reply other threads:[~2019-09-18 12:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-17 13:44 Max Neunhoeffer
2019-09-17 14:02 ` Rich Felker
2019-09-17 14:35 ` Rich Felker
2019-09-18 7:19 ` Max Neunhoeffer
2019-09-18 9:21 ` Szabolcs Nagy
2019-09-18 12:45 ` Max Neunhoeffer [this message]
2019-09-24 23:22 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190918124551.lsibbaouordfrddv@zen.arangodb.com \
--to=max@arangodb.com \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).