I'm witnessing bizarre behaviour with my dynamic C++ libraries on Solaris.
Thought I'd ask here, because y'all managed to solve the first half of my
problem };*)

Originally I was using "ld" to link my libraries, which worked fine except
that it failed to catch exceptions thrown by main-app functions called from
the libraries. I was advised to use g++ to link my libraries, since that's
what I was using to link the main application.

Success! All of the exceptions were now caught correctly.

BUT - Failure!

Previously, when the libraries were linked using ld, I could quite happily
overwrite the .so files with a new library; I coded the main app to detect
that, dlclose() the current version of the library and dlopen() the new
version, and carry on.

This is now broken. If I persuade the main app to reload the library
(without changing it), it works fine. If I change the .so file on disk and
then try the reload process, my application crashes (sometimes SEGV,
sometimes Illegal Instruction) in dlclose()

Any ideas what's going on? It's almost as if dlclose() is referring back to
the .so on disk to find out how to shut the library down, and tripping over
the fact that the code offsets are now different. But I can't understand why
that wasn't happening before with ld.

I haven't changed any other compiler or linker options, just literally
swapped "ld" for "g++". I'm using RTLD_NOW in dlopen (i.e. I'm not using the
GLOBAL or NODELETE parameters)

Any thoughts appreciated,

        Paul


{company disclaimer snipped -mod}



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Paul Harman wrote:
> I'm witnessing bizarre behaviour with my dynamic C++ libraries on Solaris.
> Thought I'd ask here, because y'all managed to solve the first half of my
> problem };*)
<snip> 
> Previously, when the libraries were linked using ld, I could quite happily
> overwrite the .so files with a new library; I coded the main app to detect
> that, dlclose() the current version of the library and dlopen() the new
> version, and carry on.
> 
> This is now broken. If I persuade the main app to reload the library
> (without changing it), it works fine. If I change the .so file on disk and
> then try the reload process, my application crashes (sometimes SEGV,
> sometimes Illegal Instruction) in dlclose()
> 
> Any ideas what's going on?

There might be a bug in the destructor for a static object, that you
are coincidentally provoking.

> It's almost as if dlclose() is referring back to
> the .so on disk to find out how to shut the library down, and tripping over
> the fact that the code offsets are now different. But I can't understand why
> that wasn't happening before with ld.
<snip>

Unix marks executable files, including shared libraries, as "busy" or
read-only so long as they are loaded into a process.  Presumably when
you rebuild the shared library it is unlinked rather than overwritten,
meaning that the old version remains on disk until it is unloaded.
If the finalisation code for the shared library needs to be paged in
when it is closed, it will be paged in from the old version and not
the new version.

However, if there is something wrong with the "busy" mechanism then
your explanation makes perfect sense.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]