Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 17 Oct 2014 08:10:48 -0400
From: Rich Felker <>
Subject: Re: Re: gthread_once

On Fri, Oct 17, 2014 at 01:42:23PM +0200, Jens Gustedt wrote:
> Hello,
> Am Freitag, den 17.10.2014, 21:36 +1100 schrieb Michael:
> > I'm not linking to glibc. gthread is a thin wrapper over pthread used
> > by gcc (i.e
> > ++/manual/ext_concurrency_impl.html).
> > 
> > 
> > It seems my problem is related to this:
> > 
> > 
> >
> > 
> > 
> > 
> > I have compiled g++ toolchain using musl-1.1.5
> > 
> > 
> > Is this a bug in musl or do i need to turn off the _GTHREAD in the
> > libstdc++ library?
> If you are really sure that your whole toolchain is built with musl,
> things like that shouldn't happen. My guess would be that there still
> is some inconsistency somewhere and a glibc version of pthreads is
> loaded before musl. It could help if you'd compile your libraries with
> debugging symbols so we could see where (which function and which
> version) this happens.

This sounds unlikely. He's static linking, so there is no separate
loading of libraries, but even if there were, musl's dynamic linker
refuses to load a library named libpthread.*.

Still, I think it would be helpful to see some indication of whether
the binary is actually a static binary that was created correctly. The
output of the "file" utility run on it, and possibly the output of
readelf -hld or even full readelf -a (although the latter might reveal
a lot about the program and be big).

> This gthread stuff doesn't seem to be too complicated. It *should*
> just generate calls to the corresponding pthread functions, but
> obviously here for you it doesn't. Your stack in the __gthread_once
> function seems to be corrupted.

It looks like it called a function via a function pointer that
happened to be null.

> Two fishy things:
>   - these are static inline functions, so to use this library you have
>     to use the same pthread implementation for all compilations of
>     application code. If anything in your tool chain goes wrong, your
>     screwed.
>   - right at the start it seems to rely on certain features of the
>     glibc implementation concerning weak symbols.
> This seems to be handled with the macros
> It could be a starting point to see how they are set and to play at
> bit with them.

These sound problematic, but if there's something wrong here, I'd be
surprised that we haven't seen failures before.


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.