Exceptions in dynamically loaded shared libraries
Lance Ball
Hi,
I'm working on an application which dynamically loads shared libraries
using the C functions dlopen() and dlsym(). I realize that the entry
points into these libraries must be C and are declared with extern "C".
However, within the functions that I make avaibale via my library, I am
using C++. The problem I am experiencing is this. When an exception is
thrown from within the library, it cannot be caught until it travels all
the way up the stack to the main application. I know that if I link
the library in instead of loading it dynamically at runtime, the exception
is caught where expected, because I've tested this. So, I'm wondering
if anyone has experienced this same problem and/or has a solution.
I'm running on Solaris 2.5 with the SunPro CC 4.1 compiler. I've submitted
a bug report to Sun, but that was about a month ago and I haven't heard
anything back.
I do have some sample code which illustrates the problem. If it would be
illustrative, I'd be happy to post it. (I'm not doing so now, because I
don't have access at the moment).
Thanks for any help.
Lance
--
| Lance Ball
| Imagination is greater than knowledge. -- A.E.
| 97 E9 02 55 96 39 AE C9 FC AE D1 AF 46 6A AB 7D
| H: l...@panix.com, W: lb...@ny.poppe.com, S: ball...@cs.nyu.edu
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Lance Ball
Hate to follow up on my own post, but I just received word from Sun on
my
error. For those of you who are interested, the command line flags to
CC which will enable this are:
CC -G -pic -o libtest.so A.o -lC
Lance
On 1 Aug 1997 05:55:17 -0400, Lance Ball (l...@panix.com) wrote:
-> Hi,
-> I'm working on an application which dynamically loads shared
libraries
-> using the C functions dlopen() and dlsym(). I realize that the entry
-> points into these libraries must be C and are declared with extern
"C".
-> However, within the functions that I make avaibale via my library, I
am
-> using C++. The problem I am experiencing is this. When an exception
is
-> thrown from within the library, it cannot be caught until it travels
all
-> the way up the stack to the main application. I know that if I link
-> the library in instead of loading it dynamically at runtime, the
exception
-> is caught where expected, because I've tested this. So, I'm
wondering
-> if anyone has experienced this same problem and/or has a solution.
-> I'm running on Solaris 2.5 with the SunPro CC 4.1 compiler. I've
submitted
-> a bug report to Sun, but that was about a month ago and I haven't
heard
-> anything back.
-> I do have some sample code which illustrates the problem. If it
would be
-> illustrative, I'd be happy to post it. (I'm not doing so now,
because I
-> don't have access at the moment).
-> Thanks for any help.
-> Lance
-> --
-> | Lance Ball
-> | Imagination is greater than knowledge. -- A.E.
-> | 97 E9 02 55 96 39 AE C9 FC AE D1 AF 46 6A AB 7D
-> | H: l...@panix.com, W: lb...@ny.poppe.com, S: ball...@cs.nyu.edu
-> [ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
-> [ about comp.lang.c++.moderated. First time posters: do this! ]
Richard M. Gabrielson
In article <5rsbph$s...@netlab.cs.rpi.edu> l...@panix.com (Lance Ball)
writes:
> ...
> I'm working on an application which dynamically loads shared libraries
After using dlopen() and dlsym() do you call the code responsible for
initializing nonlocal static objects? (If dlopen() does this
automatically then never mind, you can skip the rest of this.)
Offhand I can't remember what the specific function call might be, but
I think I've run across it in one of the "user guide" books for
Solaris.
I suspect this particularly because your application works when
statically linked. I know the typical scheme for the "singleton"
classes cin, cout, and cerr uses nonlocal static initialization, so I
wouldn't be the least surprised if exception handling also needed it.
Good luck!
--
Rich Gabrielson r.gabr...@ieee.org r...@vnet.ibm.com
IBM Test/Design Automation VOICE: 607/755-3292
1701 North St. Dept. V34, Endicott NY 13760 FAX: 607/755-5608
<< These are my own opinions. I don't speak for IBM. >>
Gary Mussar
Lance Ball wrote:
> I'm working on an application which dynamically loads shared libraries
> using the C functions dlopen() and dlsym(). I realize that the entry
> points into these libraries must be C and are declared with extern
> "C".
As far as I can tell the current CD2 doesn't seem to address dynamically
loaded code. The use of atexit() in dynamically loaded (and unloaded)
code will break. Global/static objects and static objects with
function scope may not get destructed properly before the shared
code is unloaded. It wouldn't surprise me if there were equivalent
problems with exception handling and dynamic code too.
--
Gary Mussar <mus...@nortel.ca> Phone: (613) 763-4937
Nortel FAX: (613) 763-9406
Lance Ball
{Please direct system-specific followups to the appropriate
newsgroup. -mod}
On 1 Aug 1997 15:42:52 -0400, Richard M. Gabrielson
(r...@endicott.ibm.com) wrote:
-> In article <5rsbph$s...@netlab.cs.rpi.edu> l...@panix.com (Lance Ball)
-> writes:
-> > ...
-> > using C++. The problem I am experiencing is this. When an
exception is
-> > thrown from within the library, it cannot be caught until it
travels all
-> > the way up the stack to the main application. I know that if I
link
-> After using dlopen() and dlsym() do you call the code responsible for
-> initializing nonlocal static objects? (If dlopen() does this
-> automatically then never mind, you can skip the rest of this.)
-> Offhand I can't remember what the specific function call might be,
but
-> I think I've run across it in one of the "user guide" books for
-> Solaris.
I believe you are talking about the flag to dlopen() which can be
RTLD_LAZY, RTLD_NOW, or RTLD_GLOBAL. I am calling dlopen with
the RTLD_GLOBAL, which should load all symbols immediately. As it
turns out, I had the flags wrong on the compiler <shrug>. My
immediate followup to the original posts lists them if you're curious.
Thanks,
Lance
--
| Lance Ball
| Imagination is greater than knowledge. -- A.E.
| 97 E9 02 55 96 39 AE C9 FC AE D1 AF 46 6A AB 7D
| H: l...@panix.com, W: lb...@ny.poppe.com, S: ball...@cs.nyu.edu
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Gary Mussar
Bill Leonard wrote:
> > As far as I can tell the current CD2 doesn't seem to address
> dynamically
> > loaded code.
>
Why not. They have specificed all sorts of library requirements
already. There are lots of systems that do have dynamically
loaded/unloaed code. The speci says that my embedded system must
support an atexit() function but doesn't address many other areas.
> > The use of atexit() in dynamically loaded (and unloaded)
> > code will break. Global/static objects and static objects with
> > function scope may not get destructed properly before the shared
> > code is unloaded.
>
> If that were true, it would be a very poor-quality implementation,
> IMHO.
>
> Using atexit() would break only if the library were unloaded; if you
> just
> load it and keep it around until you exit, I don't know why it
> wouldn't
> just work. The problem arises when you use dlclose(). However,
> that's
> not
> an insurmountable problem and a good implementation should handle it
> properly.
I see. So the implementors of the OS must forsee the use in C++ of
atexit() and provide a good solution for this. In my case I plan on
ripping the atexit() implementation out of the gcc library and replacing
it with my own implementation along with some routines to try and
do the right thing with functions registered with atexit() before code
gets unloaded.
--
Gary Mussar <mus...@nortel.ca> Phone: (613) 763-4937
Nortel FAX: (613) 763-9406
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]