Re: thread-stub related query

[Channa <channa.kad%gmail.com@localhost>]

Hi,

Sorry i corrected the typo in my previous mail.

Yes i agree , but the scenarios like below  get Aborted which
is not a problem with binary i believe.

1. Build the below test application without linking pthread

$ cat test.c
#include <stdio.h>
#include <dlfcn.h>

int main(void)
{
       void *handle = dlopen("libexample.so", RTLD_NOW);
       atexit(func);
       dlclose(handle);
       printf("DONE!\n");
}

2. Build the library libexample.so linked with pthread from the following code
$ cat example.c
#include <stdio.h>

void __attribute__((constructor)) exinit(void)
{
}

void __attribute__((destructor)) exexit(void)
{
}

3. When the  application  is executed it aborts
 $ ./test
Aborted

This is because
1. In the application when the library libexample.so is opened the pthread
library  constructor is called since libxx.so is linked with pthread ,
which sets the value __isthreaded to 1.
2. The application calls atexit() API which calls mutex_lock(), since
application is not linked with pthread stub function will be called.
3.  As in step 1 the __isthreaded is set to 1 which is a global
variable across the library. When __isthreaded is set thread-stub
assumes that pthread library is present and pthread library function
should be called and if thread-stub is called it is treated as error
and sends ABORT signal to the application.

Could you please help me in resolving the above issue.

Thanks & Regards,
Channa

2009/7/3 Martin Husemann <martin%duskware.de@localhost>:
> On Fri, Jul 03, 2009 at 03:51:30PM +0530, Channa wrote:
>> All the below functions in thread-stub
>>
>> __libc_mutex_init()
>> __libc_mutex_lock()
>> __libc_mutex_trylock()
>> __libc_mutex_unlock()
>> __libc_mutex_destroy()
>>
>> Send SIGABRT signal when __isthreaded is set.
>
> In NetBSD this means you have a threaded program not linked with -pthread,
> i.e. something has gone very wrong when creating the binary. That's what the
> abort is catching - you need to rebuild your binary with proper compiler
> options.
>
> I am not sure how this translates into your environment though.
>
> Martin
>