On Wed, Sep 09, 2020 at 05:49:50PM +0200, Willy Tarreau wrote:
> On Wed, Sep 09, 2020 at 05:40:05PM +0200, Vincent Bernat wrote:
> > ? 9 septembre 2020 16:58 +02, Willy Tarreau:
> >
> > > Ah I'm really angry because I tested on many platforms, *including* armhf,
> > > but now I'm not seeing it, so either I failed on one test or it depends
> > > on the compiler combination :-(
> >
> > I am getting it on Debian Unstable (gcc 10.2.0, glibc 2.31), Ubuntu
> > Focal (gcc 9.3.0, glibc 2.31) and Ubuntu Bionic (gcc 7.5.0, glibc 2.27).
>
> Thanks. Now I'm trying to work on it but can't reproduce the loading
> problem anymore... That's a heisenbug... The trick I'm trying right now
> is to really create a thread that exits on startup. This way we'll be
> certain pthread_exit() was already called once. It's much uglier than
> the first work around but should be more portable and more reliable.
OK, I've pushed this one into -dev:
f734ebfac ("BUILD: threads: better workaround for late loading of libgcc_s")
I found a more reliable and safer way to address this, exactly the same
as the one we did for backtrace(), which consists in calling the offending
function once at boot. So what we do now very early during initialization
is that we create a new thread that exits using pthread_exit(). This way
we're certain the function is usable before going further, and we don't
care if libgcc_s or whatever else provides the functionality.
I tested it on armhf, aarch64, x86_64, mipsel, ppc64le, and sparc64 with
success. It was also tested on musl which uses a different threading
library and met not issue. On Travis it's OK on all platforms. On Cirrus
and Cygwin it's still in progrss but Centos is already OK so I'm quite
confident.
Feel free to pick this patch if that helps for your builds, I'm going
to backport it to 2.2 once all platforms are happy.
Willy
