Re: Unloading sequence of GTK

[Clemens Fruhwirth <clemens endorphin org>]

Milosz Derezynski <internalerror gmail com> wrote:

> From the docs GTK+ API docs:
> 
> gtk_main():
> [...] You can nest calls to gtk_main(). In that case gtk_main_quit() will make the innermost invocation of the main loop return.
> gtk_main_quit():
> Makes the innermost invocation of the main loop return when it regains control.
> 
> You either need to clarify what you are exactly up to that seems
> impossible to you with the current mechanics, 

You want the whole story? Ok fine.

I'm interested in developing a McCLIM backend for wxcl. McCLIM is a high
level GUI toolkit for Common Lisp. I want to use wxcl for this
task. wxcl=bindings for wxWidgets. The reason? The CL commmunity can't
afford to maintain different backends for GTK/OS X/Windows. It's a
question of menpower. 

wxWidgets relays on static initializations that it makes it impossible
to call their entry functions more then once. Solutions -> reload the
library. The problem with this? wxWidgets, more particular wxGTK loads
GTK and GTK loads modules like theming itself. Because of this when
wxGTK is dlclosed, the dynamic linker tries to close GTK too but because
of the loaded modules (like theme engines) there are dependencies on
libgtk. Those dependencies can't be unloaded as the responsiblity for
loading them was with GTK. 

GTK must close this libraries otherwise, dlclose GTK won't succeed. If
so only partially. Furthermore, we wxWidgets is reloaded some parts of
GTK are reloaded some are still in memory. After playing tricks like
these I get,

(gdb) bt
#0  0x40cbcf70 in gtk_widget_show () from /usr/lib/libgtk-x11-2.0.so.0
#1  0x0804e290 in ?? ()
#2  0x4000b210 in _dl_runtime_resolve () from /lib/ld-linux.so.2
#3  0x4052efcf in wxTopLevelWindowGTK::Create () from /usr/lib/libwx_gtk2_core-2.6.so.0
#4  0x4058b2fe in wxFrame::Create () from /usr/lib/libwx_gtk2_core-2.6.so.0
#5  0x401dd78b in wxFrame_Create () from /home/clemens/ther-devel/wxc-svn/wxc/build/libwxc.so
#6  0x08048570 in call_start (fun=0x0, data=0x80488de, evt=0x804dee0) at start.c:18
#7  0x401ce937 in wxClosure::~wxClosure () from /home/clemens/ther-devel/wxc-svn/wxc/build/libwxc.so
#8  0x401ce6e9 in ELJApp::OnInit () from /home/clemens/ther-devel/wxc-svn/wxc/build/libwxc.so
#9  0x401cff11 in wxAppConsole::CallOnInit () from /home/clemens/ther-devel/wxc-svn/wxc/build/libwxc.so
#10 0x407b83a4 in wxEntry () from /usr/lib/libwx_base-2.6.so.0

I don't blame for not working when called in a weird old/new library
mix. I blame it for not unloading correctly.

The .fini section of the ELF sections is supposed to clean such
situations up. It does not seem that important as in most cases with C
application the program terminates anyway right after fini, so it does
not matter whether GTK is unloaded correctly or not. But in face, a
library reference leak is just as bad as a memory leak or a file
descriptor leak.

".fini" is the right place to correct this. 

__attribute__ ((destructor)) void fini()  
{
	/* put your code to unload theme libs and other stuff loaded by
	g_module here */    
}

I guess for theming it'd be easy, as there is only one theme engine at a
time (I might be wrong about that though). Also pango needs to clean
it's modules. pango-basic-fc.so is causing problems for me too, so the
code that loads pango-basic-fc should also come with such a destructor
(I assume that's the pango lib).

Grepping through gtk for g_module_open, there are a few other
places. For instance the "im" modules, the filesystem modules and 3 in
gdk-pixbuf/. I presume there will be a list of loaded modules somewhere,
so I guess iterating over these 3-4 lists and the current theme engine
with g_module_unload should do the trick.

-- 
Fruhwirth Clemens - http://clemens.endorphin.org 
for robots: sp4mtrap endorphin org