pthread and dynamically linked librairies

Cuero Bugot cbugot at sierrawireless.com
Thu Oct 15 08:16:05 UTC 2009


The proposed workaround (which is link the main app with pthread in addition of linking the lib with pthread) is indeed working for me. Thanks

However the debugging did show that the functions symbols were linked correctly. I rather suspect an initialization problem. Indeed the segfault is due to a null pointer assignment:
	*__libc_multiple_threads_ptr = 1;
I saw that this pointer should have been initialized into __pthread_initialize_minimal() function:
	__libc_multiple_threads_ptr = __libc_pthread_init (ptr_pthread_functions);

So either the initialization is not done or __libc_pthread_init return null (is that possible? ...)

-----Message d'origine-----
De : Natanael Copa [mailto:natanael.copa at gmail.com] 
Envoyé : jeudi 15 octobre 2009 08:41
À : Cuero Bugot
Cc : uclibc at uclibc.org
Objet : Re: pthread and dynamically linked librairies

On Wed, 2009-10-14 at 09:20 -0700, Cuero Bugot wrote:
..
> The prb is that I get a segfault when I try to use pthread_create from
> a dynamically linked library. The difference with the above fix use
> case is that I "manually" link the library using dlopen. I initially
> found this prb while trying to use the Lua (www.lua.org) VM with
> uclibc. Lua supports loading extension as so files so it uses dlopen.
> 
> I reduced and reproduced the prb with this simple use case:
> 
> 2 files (attached): test.c and lib.c
>   test.c contains the main() that will load the so file compiled from lib.c.
>   lib.c actually creates a thread. (well crashed when trying to create a thread).

Yes. I have had this too for a long time[1] and I also made a
testcase[2] for this.

I think it hs to do with uclibc having some non-pthread funcs that is
used when pthread is not linked in. So when you dlopen something linked
to pthread, the pthread version of the symbols should have been used,
but they arent, since pthread was not there during first link.

The apps that this affects is scripting languages lua, ruby and php[3]
together with the sqlite3 binding. I think it also affects cpufreqd.

The way I have worked around it is to force linking to pthread in the
main binary[4][5][6]. I havent bothered to try fix it in uClibc since we
soon will have NTPL.

[1] https://bugs.gentoo.org/show_bug.cgi?id=189804
[2] http://dev.alpinelinux.org/~ncopa/dl-pthread/
[3] http://redmine.alpinelinux.org/issues/show/183
[4] http://git.alpinelinux.org/cgit/aports/commit/?id=13892e864cacf21636be25149eabcd3e2537f7aa
[5] http://git.alpinelinux.org/cgit/aports/commit/?id=8853a68804a505e1af90ccbbfc9295551a5d3a6c
[6] http://git.alpinelinux.org/cgit/aports/commit/?id=9881efaf35fb10a9145a18d71f9af6f019ccab81

-nc




More information about the uClibc mailing list