On 10/22/07, Benoit Fouet <benoit.fouet@xxxxxxxxxxxxxx> wrote:
> Hi,
>
> Steve Graegert wrote:
> > Benoit,
> >
> > On 10/22/07, Benoit Fouet <benoit.fouet@xxxxxxxxxxxxxx> wrote:
> >
> >> Hi Steve,
> >>
> >> Steve Graegert wrote:
> >>
> >>> Hi Benoit,
> >>>
> >>> On 10/22/07, Benoit Fouet <benoit.fouet@xxxxxxxxxxxxxx> wrote:
> >>>
> >>>
> >>>> Hi,
> >>>>
> >>>> Steve Graegert wrote:
> >>>>
> >>>>
> >>>>> As a side note: you can safely use dlopen() to load shared libraries,
> >>>>> whether or not they depend on libpthread.so, as long as the main
> >>>>> program was initially threaded. The other way round is dangerous and
> >>>>> mostly not allowed.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>> could you please elaborate a bit on that ? i cannot see why this is
> >>>> dangerous.
> >>>>
> >>>>
> >>> I was referring to making an application multithreaded at runtime.
> >>> Therefore you cannot use dlopen() to dynamically add libpthread.so to
> >>> a process when the main program is not __initially threaded__. By
> >>> "initially threaded" I mean that the libpthread.so library is
> >>> initialized at program start, either because the main program links
> >>> against libpthread.so directly, or because it links against some other
> >>> shared library that links against libpthread.so.
> >>>
> >>> Dynamically changing the process environment from "nonthreaded" to
> >>> "threaded" is dangerous and rarely useful (I actually doubt that this
> >>> "feature" is useful at all).
> >>>
> >> If i understand correctly what you're saying, you cannot have something
> >> like:
> >>
> >> int main(int argc, char *argv[]) {
> >> /* ... */
> >> foo = dlopen("bar.so");
> >> /* use bar.so functions, clean, etc... */
> >> }
> >>
> >> if bar.so is multithreaded (and thus, linked to libpthread.so) and you
> >> don't compile your main program with -lpthread option.
> >> did i understand you right ?
> >>
> >> this would mean you may need to link against pthread library, just in
> >> case the library(ies) you dlopen might use it ?
> >>
> >
> > Linking against a multi-threaded library at compile time, turns the
> > main program into a multi-threaded program even though no use of
> > threads is being made at all.
> >
> >
>
> i agree, but this was not what i asked.
> consider a library foo using threads.
> consider a main program bar only linked to dl.
> chat you said is that bar cannot use sanely foo functions, because it is
> not multithreaded itself, right ?
Basilcally yes, but let me summarize some important points:
Suppose you have an application that is not linked against libpthread,
neither directly nor indirectly (just as you stated earlier). The
init code used to set up the main program doesn't care about threads,
because it assumes that they won't be used anyway. Hence you have a
non-threaded program. The important thing is the init code, not
whether the main program makes call to pthread_* and its siblings or
not.
Now, this non-thread program loads a shared object using dlopen()
which is linked against libpthread, thus resulting in an "abort trap".
I remember Apache to crash with an abort trap when loading mod_perl
although it has been build without errors. Recompiling apache with
CFLAGS+=-pthread fixed the problem.
Example:
#include <dlfcn.h>
#include <stdio.h>
#include <stdlib.h>
int main(void) {
void *h; // the handle
printf("Trying to load libpthread.so\n");
h = dlopen("libpthread.so", RTLD_LAZY);
printf("libpthread.so loaded successfully\n");
dlclose(h);
return EXIT_SUCCESS;
}
This can be worked around by linking against libpthread, because this
causes the initialization code used to set up the program to be
overridden.
Considering the previous example, doing:
cc test.c
./a.out
results in a crash. But
cc -lpthread test.c
./a.out
won't. Even
cc test.c
LD_PRELOAD=/usr/lib/libpthread.so ./a.out
will work. It's the initialization code that matters, not if threads
are used or not.
\Steve
--
Steve Grägert
DigitalEther.de
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
