[Desktop_architects] ELF scoping problem

[Bastian, Waldo]

If you were to dlopen your libs, you would solve this by passing the
RTLD_LOCAL flag, right? I admit that I don't know how to do this when
you don't use dlopen but directly link against the lib instead.

Cheers,
Waldo
 
Intel Corporation - Channel Platform Solutions Group - Hillsboro, Oregon

>-----Original Message-----
>From: desktop_architects-bounces at lists.osdl.org
[mailto:desktop_architects-
>bounces at lists.osdl.org] On Behalf Of Mike Hearn
>Sent: Monday, December 11, 2006 11:35 AM
>To: desktop_architects at osdl.org
>Subject: [Desktop_architects] ELF scoping problem
>
>During my talk I made a throwaway reference to a design problem with
>ELF that tended to whack ISVs. I just debugged the *second* instance
>of this with a Google desktop Linux app in about as many weeks, and it
>reminded me that I never really explained what it was.
>
>I used this as an example of a problem that could get fixed, but
>probably won't, because the relevant people have no real incentive to
>fix it. It typically only shows up when you have multiple versions of
>a library loaded into the same process image, something that tends not
>to happen inside a distro due to mass recompiles fixing everything to
>the same version. It happens a lot more for ISVs who have to pick one
>library version and go with it.
>
>The basic issue is this: take a symbol, call it foo_init, that is
>defined as such in version 1 of the library:
>
>char *foo_init() {
>    return "zoink";
>}
>
>In version 2 of the library it is changed to be like this:
>
>char *foo_init() {
>    return strdup("zoink");
>}
>
>Clearly the ABI of this function has changed. In the first version it
>is an error to free() the result, in the second version is required.
>Because the libfoo author is savvy he notices this is an ABI break,
>documents it, and renames the library from libfoo.so.1 to libfoo.so.2
>
>Now as it happens, libfoo is used by libwidget internally. Now the
>BarLinux distro wants to upgrade to the new libfoo so it patches
>libwidget to use free() on the result, as is correct. Because BarLinux
>updates every package to use the new version, this works.
>
>Now Google Whatever is released and it's compiled against libfoo.so.1,
>because this version is present on both older and newer distros. It
>also uses libwidget. So the link tree looks like this:
>
>google-whatever
>    - libfoo.so.1
>    - libwidget.so.0
>         - libfoo.so.2
>
>We now have two versions of the same library loaded into memory at
>once. This is perfectly sane and reasonable on, say, Windows .... but
>it doesn't work on Linux.
>
>What happens is the foo_init() call in libwidget.so.0 is NOT linked to
>the definition in libfoo.so.2 as you might expect, bu rather to
>libfoo.so.1, therefore it will try and free() a string that is
>statically allocated causing a crash.
>
>This is not the exact failure case I just debugged, but it is somewhat
>similar.
>
>This scenario happens a lot with the C++ standard library, because it
>is very widely used by many things, and because ISVs tend to use C++ a
>lot more than open source projects do.
>
>It can be "fixed" in some cases using a variety of special case hacks
>that almost nobody knows about, but clearly this situation isn't ideal
>and it's not the ISVs fault - nobody can protect themselves against
>this failure case. It just isn't possible.
>
>thanks -mike
>_______________________________________________
>Desktop_architects mailing list
>Desktop_architects at lists.osdl.org
>https://lists.osdl.org/mailman/listinfo/desktop_architects