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

[Petr Baudis <pasky at suse dot cz>]

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