This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: dlopen/dlclose behaviour - real reloading from disk required.


On Wed, Dec 09, 2009 at 07:47:12PM +0000, Przemysław Firszt wrote:
> Hi,
> I'm working on an input driver for xorg. Xorg server uses dlopen/dlclose
> from glibc to load module driver. I want to modify/update to driver
> module without shutting down xorg. 
> 
> Currently situation looks like that:
> 1. xorg started
> 2. load the input driver module (using whole xorg mechanism, but it goes
> down to dlopen)
> 3. test the driver
> 4. unload the driver module (as above, but dlclose)
> 5. modify the driver
> 6. reinstall the driver module (or remove from disk/reinstall - doesn't
> make any difference)
> 7. load the input driver
> I'm expecting to see _new_ version of the driver loaded at point 7, but
> instead the old version is loaded. I presume that a copy of the old
> version of the driver is somewhere in the memory and it gets loaded
> instead of my new driver.
> 
> I used lsof to be sure that nothing locks the driver module. I played
> with ldconfig -n, but it didn't help.
> 
> How can I force real reloading of the modified version?
> 
> I can provide a test case if someone wants to check it.

That would be good. I'm not completely familiar with ld.so innards, but
according to dlclose() documentation, it might be that some other
library still keeps the refcount up... You could also try to watch in
detail what ld.so does by setting $LD_DEBUG appropriately (see man
ld.so).

				Petr "Pasky" Baudis


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]