The bug seems to be also present for NPTL (i386 at least). It seems that's event the "same" bug: *__libc_multiple_threads_ptr = 1;
[Thread debugging using libthread_db enabled] [New Thread 0x400 (LWP 11685)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x400 (LWP 11685)] 0xf7f550b5 in __pthread_initialize_manager () at libpthread/linuxthreads/pthread.c:641 641 *__libc_multiple_threads_ptr = 1; (gdb) l 636 637 __pthread_multiple_threads = 1; 638 #if TLS_MULTIPLE_THREADS_IN_TCB || !defined USE_TLS || !TLS_DTV_AT_TP 639 __pthread_main_thread->p_multiple_threads = 1; 640 #endif 641 *__libc_multiple_threads_ptr = 1; 642 643 #ifndef HAVE_Z_NODELETE 644 if (__builtin_expect (&__dso_handle != NULL, 1)) 645 __cxa_atexit ((void (*) (void *)) pthread_atexit_retcode, NULL, -----Message d'origine----- De : [email protected] [mailto:[email protected]] De la part de Cuero Bugot Envoyé : jeudi 15 octobre 2009 10:16 À : [email protected] Objet : RE: pthread and dynamically linked librairies 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:[email protected]] Envoyé : jeudi 15 octobre 2009 08:41 À : Cuero Bugot Cc : [email protected] 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 _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
