From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14683 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Max Neunhoeffer Newsgroups: gmane.linux.lib.musl.general Subject: Re: Bug report, concurrency issue on exception with gcc 8.3.0 Date: Wed, 18 Sep 2019 09:19:31 +0200 Message-ID: <20190918071931.lkuf45ltcrdrdxjy@zen.arangodb.com> References: <20190917134422.aootviums4hdtell@zen.arangodb.com> <20190917140227.GW9017@brightrain.aerifal.cx> <20190917143510.GX9017@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="247050"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: NeoMutt/20180716 To: musl@lists.openwall.com Original-X-From: musl-return-14699-gllmg-musl=m.gmane.org@lists.openwall.com Wed Sep 18 09:19:49 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1iAUFf-001267-Vq for gllmg-musl@m.gmane.org; Wed, 18 Sep 2019 09:19:48 +0200 Original-Received: (qmail 7641 invoked by uid 550); 18 Sep 2019 07:19:45 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 7621 invoked from network); 18 Sep 2019 07:19:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arangodb.com; s=google; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=yS/Od5PudOcb2uJl5k82ZucOocul/tTk4A2T0rQfcCg=; b=K1ihuF3tzOl2GDU/2uUiFGTTsCLoLYC1ttZ8IMqqHaNGe9P/3RkwjpPFFFSMss/BlA DRtt/QLCZRDshQp9B/LmiNpnyQnQldgbD8/iHg/RzjYCJvmZvXnXWcrJ6l7htTTvBDzX w+TG9rUUko/yt0aYFOGKhUpqtDtcjY3ICqZtOwucoG3imnMxV0U9L5kidBqGsgS2DnX5 giQyJcNe1sjw+r4JOW160vZdgM9znBW5mFPvX1KGoN7p+/RTaFzt3l8l82fBc6G1hvHj 5bKk80fRWB5tGiWga8Zhb7ejSB8JUt9yrv1XRmFiEx4HnBZtnJuWAJzhbC52wrlCMoHG rHwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=yS/Od5PudOcb2uJl5k82ZucOocul/tTk4A2T0rQfcCg=; b=JvWuGMbjTOdglCGh6hWvO/AfStbFHtUh2cuzLxHn3w6Tzd0/DD00uQRx18d3xGSkGL 6bA+2c+5SWhsu+hiHrTNj4gGd1wDy1SWnvKi+a9a4RzfxMEuHfdiggO2PQH7+I4RzMgJ xBGitVhzoj5DncdpJzYrSZZHPFZX5zAxX3QJGcfHijujP3wN5tU+U1wEzsrTGgyNZ4Ac 9ArUxHhrbyXtiwWntsDFM8JuKjRwuJ4PNe/1kKT55OUcNjzrioMu+bNZqzBkuZwfc7QU MLE6yCNdol8DPFMolqiO/nj0v/fJ92Gjb9VT7NCXV9KerFsOdadVIEf7fPkGJQ+8Mvo1 f3Gw== X-Gm-Message-State: APjAAAUfgMR9GaFSo0KxcImgrHiYB/+pxl+nQCzlK0iM0ZisR40nr+l1 9rSYd+YAQPOTCcu5XVPYpnsaxXqHSeegg3HyyYIMKNoF14eMv1TnDwJzoKGlp1MziiWVBOXd8No eeT650fhtcUoGIohQcan3P0BRCsN+1pPn09oCOOXn9k48ibdK6GYixzi4g95mckc= X-Google-Smtp-Source: APXvYqzReEzpFVJl7pLn35seWMHSDXXkEcf84OiUpRDrTv3Kb9KQmlDCdrD5J5Lew7xykP8LzRN4Gg== X-Received: by 2002:adf:8444:: with SMTP id 62mr1922146wrf.202.1568791172660; Wed, 18 Sep 2019 00:19:32 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20190917143510.GX9017@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:14683 Archived-At: Hi Rich, 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. 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