Hi all,

RHL7.2, glibc2.2.4, pthread.
Same dlsym() went well until segfault with stack trace below today:

#0  _dl_lookup_symbol (undef_name=0x8068e98 "callsub", undef_map=0x40016c00,
ref=0x42b6fef4, symbol_scope=0x814e2bc, type_class=0, explicit=1)    at
do-lookup.h:80
#1  0x40c50e70 in _dl_sym (handle=0x1c80, name=0x8068e98 "callsub",
who=0x0)at dl-sym.c:62
#2  0x40acc450 in dlsym_doit (a=0x42b7003c) at dlsym.c:39
#3  0x4000d7c3 in _dl_catch_error (objname=0x837dda8,
errstring=0x837ddac,operate=0x40acc430 <dlsym_doit>, args=0x42b7003c) at
dl-error.c:152
#4  0x40acc6fb in _dlerror_run (operate=0x40acc430
<dlsym_doit>,args=0x42b7003c) at dlerror.c:130
#5  0x40acc416 in dlsym (handle=0x814e108, name=0x8068e98 "callsub")     at
dlsym.c:51
#6  0x08065378 in myclass::calllib (this=0x83938d8, bufout=0x42b7ef9c) at
mychildthread.cpp:87

The code snippet as thus:
// mychildthread.cpp
....
  plib = dlopen("mylib", RTLD_LAZY);
   if (!plib) {
         error = dlerror();
         deb_dump(...);
         return ERR_LIB;
   }
   dlerror();
   callsub = ( func_callsub )dlsym(plib, "callsub"); // line 87
   if ((error = dlerror())) {...}
....

App's main thread dlopen() "mylib" and dlclose() it only when it exits.
Should each (child)thread uses a mutex for dlopen()/dlsym()/dlclose() for
above issue? my app doesn't. If not, what is the possible reason?

Thanks in advance


-sean

Hello Sean, 

> RHL7.2, glibc2.2.4, pthread.
> Same dlsym() went well until segfault with stack trace below today:

[snip] 

> The code snippet as thus:
[snip] 

> App's main thread dlopen() "mylib" and dlclose() it only when it exits.
> Should each (child)thread uses a mutex for dlopen()/dlsym()/dlclose() for
> above issue? my app doesn't. If not, what is the possible reason?

I can't do anything with your input (and probably the others neither).

Pls could you post a minimal, working, code that shows your issue. It
doesn't need to be you full code (which can be proprietary).

TIA,
Loic.

"Loic Domaigne" wrote:

>I can't do anything with your input (and probably the others neither).
>...

Thanks for reply.
Could be another developer updated the lib without restart my app the
reason? I'm not very sure though.