[uClibc] ldso bug in uclibc?

Andrew de Quincey adq_dvb at lidskialf.net
Mon Nov 8 03:18:42 UTC 2004


Hi, now that I have gdb working, I've been tracking down the actual bug that I 
needed to debug gdb for.

Its in the Helix client. Helix consists of a set of shared libraries - 
plugins. Each plugin .so has a public set of standard C API symbols - 
CanUnload(), CanUnload2() etc. Each plugin's symbols have the same name.

Helix core loads the shared library using libdl and requests these symbols by 
name. This seems to work fine - if it asks for CanUnload from pluginX.so, it 
gets the pointer to the method in pluginX.so.

There is a cleanup thread that runs that removes unused plugins from memory - 
If CanUnload() returns 0, it removes it. The problem I'm having is that one 
of the plugins unloads when it is still in use.

This plugin has an implementation of the above two methods as follows:

int CanUnload2() {
 return CanUnload()
}

int CanUnload {
 -- check stuff and return appropriate value
}

I've added in tracing, CanUnload2() is called correctly. However, when it 
calls CanUnload(), the method in a *different* plugin is called - which 
coincidentally returns 0, causing the one in use to be unloaded. Which 
doesn't have good results. :)

Note that I'm using -fPIC as these are shared libraries on a powerpc 405, so 
the call to CanUnload from CanUnload2 goes through the PIC.. er table? sorry 
not sure of the terminology here. I'm guessing the PIC table entry for 
CanUnload is accidentally being populated with CanUnload from the first .so 
it loaded.

This has to be a bug in uclibc. These plugins have been in Helix for a while, 
and if they didn't work they would have been fixed ages ago.

I'm using a uclibc snapshot from 06.11.2004.



More information about the uClibc mailing list