pthread and dynamically linked librairies

[Cuero Bugot]

Hi all,

I reopen the subject with a potential new bug submission. I've seen that this topic has been treated here a couple of time already, and that there is a fix that may be related to that specific prb (see commit r21980 | vapier | 2008-05-15 04:03:13 +0200 (Thu, 15 May 2008) | 9 lines)


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).

I used uClibc-0.9.30.1

To compile the file I did:
	i686-linux-gcc -o test test.c -ldl
	i686-linux-gcc -fPIC -shared -o libtest.so lib.c -lpthread
then to test it:
	export LD_LIBRARY_PATH=.
	./test libtest.so

Gdb gives me this:

[Thread debugging using libthread_db enabled]
[New Thread 0x400 (LWP 32200)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x400 (LWP 32200)]
0xf7f23621 in __pthread_initialize_manager () at libpthread/linuxthreads.old/pthread.c:515
515	  *__libc_multiple_threads_ptr = 1;
(gdb) l
510	  int manager_pipe[2];
511	  int pid;
512	  int report_events;
513	  struct pthread_request request;
514	
515	  *__libc_multiple_threads_ptr = 1;
516	
517	  /* If basic initialization not done yet (e.g. we're called from a
518	     constructor run before our constructor), do it now */
519	  if (__pthread_initial_thread_bos == NULL) pthread_initialize();
(gdb) display __libc_multiple_threads_ptr
1: __libc_multiple_threads_ptr = (int *) 0x0


So __libc_multiple_threads_ptr is null so it seg fault !

Going further would require specific knowledge of the implementation.

Any one has an idea ?


PS: I reproduced it on i686 architecture, but I initially found the bug on arm target.


C.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test.c
URL: <http://lists.busybox.net/pipermail/uclibc/attachments/20091014/1b914c42/attachment.diff>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lib.c
URL: <http://lists.busybox.net/pipermail/uclibc/attachments/20091014/1b914c42/attachment-0001.diff>