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.



#include <netdb.h>
#include <stdio.h>
#include <stdint.h>
#include <dlfcn.h>

typedef int (*func)(void);

int main(int argn, char* argv[])
{
    if(argn<2 || !argv[1])
    {
        printf("give a so name!\n", argv[1]);
        return -1;
    }

    void *lib = dlopen(argv[1], RTLD_NOW);
    if(!lib)
    {
        printf("file %s not found\n", argv[1]);
        return -1;
    }

    func f = dlsym(lib, "runthething");
    if(!f)
    {
        printf("function runthething not found\n", argv[1]);
        return -1;
    }

    f();

    printf("Bye !\n");
    return 0;
}
#include <pthread.h>
#include <stdio.h>

void* exec(void* t)
{
 printf("Thread\n");
 return 0;
}

int runthething()
{
  pthread_t execThread;

  pthread_create(&execThread, 0, exec, 0);
  printf("debug1.1\n");
  pthread_detach(execThread);

  printf("debug2\n");

 sleep(5);
  return 1;
}

_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

[Natanael Copa-3]

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
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

[Joakim Tjernlund-2]

uclibc-bounces@... wrote on 15/10/2009 08:41:10:

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

Looked at the bug and if this is the same(I am not convinced)
it is a matter of teaching ldso to respect the NO_DELETE flag
in the DYNAMIC section. This will be needed for NPTL too if not
already impl.
I see that modern NPTL has INITFIRST set too, not sure if that
is important for pthreads in uClibc though.

> [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
> uClibc@...
> http://lists.busybox.net/mailman/listinfo/uclibc
>

_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

[Mike Frysinger]

On Thursday 15 October 2009 02:41:10 Natanael Copa wrote:

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

i dont really understand what you're saying, but i'm pretty sure what you
describe strictly doesnt matter.  the stub forwarding symbols in uClibc check
for libpthread availability at every function invocation.  so loading it later
rather than up front should be fine.

not saying there isnt a problem somewhere, just that your brief theory is
probably sniffing the wrong rabbit hole.

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

people are testing post my commit fa8710bf5c7b0aaf7d687d9831fbd01b71da85ae ?
-mike


_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

[Cuero Bugot]

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@...]
Envoyé : jeudi 15 octobre 2009 08:41
À : Cuero Bugot
Cc : uclibc@...
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
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

[Cuero Bugot]

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 : uclibc-bounces@... [mailto:uclibc-bounces@...] De la part de Cuero Bugot
Envoyé : jeudi 15 octobre 2009 10:16
À : uclibc@...
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:natanael.copa@...]
Envoyé : jeudi 15 octobre 2009 08:41
À : Cuero Bugot
Cc : uclibc@...
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
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc