[PATCH 1/1] Look for ModuleData only in appropriate library

Michal Srb msrb at suse.com
Wed Jun 27 11:20:08 PDT 2012

On Wednesday 27 of June 2012 12:52:38 Adam Jackson wrote:
> On Wed, 2012-06-27 at 18:04 +0200, Michal Srb wrote:
> > Calling dlsym with handle of the module library
> > instead of RTLD_DEFAULT prevents increasing reference
> > counter of the library and so allows it to be
> > really unloaded if UnloadModule is called on it
> > later.
> That's not how I would have expected libdl to behave.  I wouldn't have
> thought dlsym success would increase the refcount of the providing
> object, given that there's no way in the API to release that reference;
> if dlsym _does_ bump the refcount I'd have thought the resolution scope
> would not be a factor.
> I'd be interested to know when and why this behaviour was added.  A
> quick read of freebsd's dlsym doesn't appear to have that behaviour to
> me, but then neither does a quick read of glibc's dlsym.

My previous claims about the reference counter were based on one stackoverflow.com comment and mainly experiments that confirmed that behavior. I couldn't find any related documentation and glibc code is not my favorite reading.

I debugged in glibc now and found it's not the reference counter but DF_1_NODELETE flag being set as result of dlsym(RTLD_DEFAULT, ...).
The DF_1_NODELETE flag is internal flag. It is also set when RTLD_NODELETE flag is specified in dlopen.

Backtrace from glibc 2.14.1 looks like this:

#0  add_dependency       <-- add DF_1_NODELETE flag
#1  _dl_lookup_symbol_x  <-- calls the above because of DL_LOOKUP_ADD_DEPENDENCY flag
#2  do_sym               <-- calls above with DL_LOOKUP_ADD_DEPENDENCY flag because of handle == RTLD_DEFAULT
#3  dlsym_doit
#4  _dl_catch_error
#5  _dlerror_run
#6  __dlsym
#7  doLoadModule         <-- dlsym(RTLD_DEFAULT, ...)
#8  xf86LoadModules
#9  InitOutput
#10 main

The patch remains valid, the explanation in the comment has to be corrected. Sorry for making claims without proper investigation.

Michal Srb

More information about the xorg-devel mailing list