The Cairo operating system [LWN.net]

The Cairo operating system

Posted Jul 6, 2006 20:27 UTC (Thu) by oak (guest, #2786)
In reply to: The Cairo operating system by nix
Parent article: Cairo release 1.2.0 now available

You forgot one additional problem with dlopen() which is debugging
things for libraries which have been dlclose()d.

Trying to determine with Valgrind in a large application doing lots
of dlopen()s and dlclose()s from which dlopened library a memory
leak is coming is "interesting". Only way to debug in that situation
is to change the code not to do dlclose() which then can have some
other problems when the libraries are dlopen()d another time...

And yes, the performance and memory usage difference between
prelinked libraries and dlopen()ed libraries is very noticable
if you have a lot of them and especially if they use C++.
For large C++ program/library not being able to do prelinking
can easily waste megabytes of memory per process (if there are
tens of thousands of symbols that need resolving).

(Log in to post comments)

The Cairo operating system

Posted Jul 7, 2006 0:30 UTC (Fri) by nix (subscriber, #2304) [Link]

dlclose() also interacts... interestingly with VM randomization.

I found a bug in Subversion (with --enable-dso) a while back which reduces to dlopen(), store a pointer to a function in the shared object in a data structure, dlclose(); later dlopen() again, call through the function pointer, *boom*; there's no guarantee that the dlopen() is at the same address this time, and with VM randomization it's pretty much guaranteed to be different.

Oops.

I think this would likely also kill C++ RTTI through repeatedly-dlopen()ed shared libraries, since that relies on pointer comparisons. The lesson in all this is to avoid dlclose().

The Cairo operating system

Posted Jul 7, 2006 8:28 UTC (Fri) by xoddam (subscriber, #2322) [Link]

> The lesson in all this is to avoid dlclose().

... er ... or at least to invalidate any dlsym()s you have cached when
you dlclose(), as any *sane* developer would, and look them up afresh
if/when you re-dlopen() the library.

The Cairo operating system

Posted Jul 7, 2006 10:15 UTC (Fri) by nix (subscriber, #2304) [Link]

Well, yes, but it can be hard to keep track of such things if you're keeping pointers to some entities which are dlsym()ed from different places and others which are not, in the same data structure.

The Cairo operating system

Posted Jul 7, 2006 19:38 UTC (Fri) by oak (guest, #2786) [Link]

If you need to change the backend. For example when you migrate your
application window from local display (with OpenGL support) to a remote
display. Gtk has already some support for display migration.

For something like in-process panel applets dlclose() & dlopen()
make sense. User might very well want to change the panel applets
at run-time...

The Cairo operating system

Posted Jul 7, 2006 20:01 UTC (Fri) by evgeny (guest, #774) [Link]

Fine, but this still doesn't explain why you insist on closing the first _backend_? What you describe is switching from an _instance_ of a device to an instance of another device. Say, the X11 device, once registered, could allow you to have several Drawables (Pixmap/Window) in the same app - e.g., one for the main window, another one for File/Open... preview, etc, which doesn't mean the X11 device plugin should be registered/unregistered each time. Just as the dynamic loader does symbol resolving only once, similarly, all available/enabled backend plugins need to be initiated only once.

The Cairo operating system

Posted Jul 7, 2006 20:24 UTC (Fri) by oak (guest, #2786) [Link]

> Fine, but this still doesn't explain why you insist on closing
> the first _backend_?

I did not say any such thing. :-)
I was merely commenting on the pros&cons of dlopen() and dlclose().
Whether some piece of code actually uses them, is up to the code...

> Say, the X11 device, once registered, could allow you to have several
> Drawables (Pixmap/Window) in the same app - e.g., one for the main
> window, another one for File/Open...

Note that those are different windows. (X) display migration means
moving all of applications (open) windows from one (e.g. local) X server
to another X server. For example you take a PDA with you to a meeting
and you want to show something you've scribbled with it briefly on the
projector before continuing using the same program. Or you have in your
desktop machine multiple graphics cards each running a separate X server
and you want to migrate some of your apps from one X server to another
*without closing* the apps.