Re: gthread_once

Re: gthread_once

[Michael]

[-- Attachment #1: Type: text/plain, Size: 1795 bytes --]

I'm not linking to glibc. gthread is a thin wrapper over pthread used by
gcc (i.e
https://gcc.gnu.org/onlinedocs/libstdc++/manual/ext_concurrency_impl.html).

It seems my problem is related to this:

http://www.riscos.info/pipermail/gcc/2008-July/004525.html

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?
------------------------------------------------------------------

Hi,

Am Dienstag, den 14.10.2014, 17:07 +1100 schrieb Michael:
> I have compiled my app using musl entirely statically however when it
> is run on initialization it crashes with the attached stacktrace under
> x86_64.  Is this because the local stuff in musl is not fully
> finished?
>
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000000000 in ?? ()
> (gdb) bt
> #0  0x0000000000000000 in ?? ()
> #1  0x00000000006ccecf in __gthread_once ()
> #2  0x00000000006cd285 in std::locale::_S_initialize() ()
> #3  0x00000000006cd012 in std::locale::locale() ()
> #4  0x0000000000683614 in std::basic_streambuf<char,
> std::char_traits<char> >::basic_streambuf() ()
> #5  0x00000000006ae590 in __gnu_cxx::stdio_sync_filebuf<char,
> std::char_traits<char> >::stdio_sync_filebuf(_IO_FILE*) ()
> #6  0x0000000000684beb in std::ios_base::Init::Init() ()
> #7  0x00000000004021ee in
> _GLOBAL__sub_I__ZN9wxPrivate18GetUntypedNullDataEv ()
> #8  0x00000000006f5056 in __do_global_ctors_aux ()
> #9  0x000000000040012b in _init ()
> #10 0x0000000000000000 in ?? ()

This looks as if you are using the native C++ lib, and this is using
internal stuff from glibc under the hood. In particular, here it seems
to be using glibc's implementation of pthread_once to initialize things.

Not surprising that this doesn't work.

Jens

[-- Attachment #2: Type: text/html, Size: 2305 bytes --]

Re: Re: gthread_once

[Jens Gustedt]

[-- Attachment #1: Type: text/plain, Size: 1989 bytes --]

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 https://gcc.gnu.org/onlinedocs/libstdc
> ++/manual/ext_concurrency_impl.html).
> 
> 
> It seems my problem is related to this:
> 
> 
> http://www.riscos.info/pipermail/gcc/2008-July/004525.html
> 
> 
> 
> 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 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.

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

__GXX_WEAK__ && _GLIBCXX_GTHREAD_USE_WEAK

It could be a starting point to see how they are set and to play at
bit with them.

Jens

-- 
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Re: gthread_once

[Rich Felker]

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 https://gcc.gnu.org/onlinedocs/libstdc
> > ++/manual/ext_concurrency_impl.html).
> > 
> > 
> > It seems my problem is related to this:
> > 
> > 
> > http://www.riscos.info/pipermail/gcc/2008-July/004525.html
> > 
> > 
> > 
> > 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
> 
> __GXX_WEAK__ && _GLIBCXX_GTHREAD_USE_WEAK
> 
> 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.

Rich

Re: gthread_once

[Michael]

[-- Attachment #1: Type: text/plain, Size: 5552 bytes --]

Essentially my plan is to compile my console only app for android but using
the musl library instead of bionic. Im compling for standard x86_64 linux
first to see if its viable. My app is plain c++ using wxwidgets (base only)
and boost threads/system. I compiled these dependencies using CC/CXX/AR etc
vars set to x86_64-linux-musl-gcc etc... and they compile fine and appear
to be only linking to musl libraries as i used -v on the compliation and
watched the directories it pulls in.

Could the pthread_once be something to do with this thread
http://sourceware-org.1504.n7.nabble.com/PATCH-Provide-pthread-atfork-in-libc-nonshared-a-and-libc-a-td246012.html#a247866


Runing file against my binary is:
./vhui: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), statically
linked, not stripped

If i run readelf -hld:

ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x403309
  Start of program headers:          64 (bytes into file)
  Start of section headers:          14776944 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         4
  Size of section headers:           64 (bytes)
  Number of section headers:         28
  Section header string table index: 25

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x0000000000417b4c 0x0000000000417b4c  R E    200000
  LOAD           0x0000000000417b50 0x0000000000a17b50 0x0000000000a17b50
                 0x0000000000014b98 0x0000000000037168  RW     200000
  TLS            0x0000000000417b50 0x0000000000a17b50 0x0000000000a17b50
                 0x0000000000000000 0x0000000000000018  R      8
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     10

 Section to Segment mapping:
  Segment Sections...
   00     .init .text .fini .rodata .eh_frame .gcc_except_table
   01     .ctors .dtors .jcr .data.rel.ro .got .got.plt .data .bss
   02     .tbss
   03

There is no dynamic section in this file.

---------- Forwarded message ----------
> From: Rich Felker <dalias@libc.org>
> To: musl@lists.openwall.com
> Cc:
> Date: Fri, 17 Oct 2014 08:10:48 -0400
> Subject: Re: [musl] 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 https://gcc.gnu.org/onlinedocs/libstdc
> > > ++/manual/ext_concurrency_impl.html).
> > >
> > >
> > > It seems my problem is related to this:
> > >
> > >
> > > http://www.riscos.info/pipermail/gcc/2008-July/004525.html
> > >
> > >
> > >
> > > 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
> >
> > __GXX_WEAK__ && _GLIBCXX_GTHREAD_USE_WEAK
> >
> > 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.
>
> Rich
>
>

[-- Attachment #2: Type: text/html, Size: 7672 bytes --]