KLibLoader is crashing
Andreas Hartmetz
ahartmetz at gmail.com
Sun Sep 2 21:43:30 BST 2007
On Sunday 02 September 2007 20:18:17 Thiago Macieira wrote:
> wrote:
> >Hi,
> >
> >I've found the problem. This one is a tricky one.
> >
> >The problem is a conceptual one. A library now can provide both the
> >configuration dialog for a plugin and the plugin itself.
> >
> >If a plugin is not loaded and its configuration dialog is shown, then
> >the library is loaded, and after Cancel or OK is clicked, the library
> >is unloaded. That doesn't represent a problem.
> >
> >The problem comes when a plugins is loaded and the configuration
> >dialog is shown. The library is "loaded", then when the configuration
> >dialog is closed, the library is _UNLOADED_, but it was _still
> >providing_ the plugin itself (that is still loaded) what makes it
> >crash.
>
> The way I see it, there are two conceptual problems here:
>
> 1) each load should be counted. The module (the .so file) must not be
> unloaded until as many unloads have been issued as loads. It's like a
> mutex: if you load (lock), you must unload (unlock) exactly as many
> times, never less, never more.
>
> 2) unloading is broken, completely. It brings too many problems. I want to
> remove the whole module unloading code from KDE -- but leave the API so
> that there's the impression that unloading happens. Probably leave some
> debugging about the number of unloads being different than the number of
> loads.
Hmm. Are you saying that it's technically impossible or very hard to make
library unloading not dangerous, or just that KDE doesn't implement it right?
Reference counting should work if unloading is doable. It semi-works in kmail
for folders and it should be very easy to get right for libraries as library
loading/unloading is so uncommon that you can easily check all the relevant
code paths for correctness.
More information about the kde-core-devel
mailing list