I've got an app that loads 2 CFM shared libraries. Upon quitting, it
crashes in __destroy_global_destructor_chain(), and it looks to me like
the data in that chain is being overwritten at some point.
I've added some code to my app to walk this chain and verify the
contents at various stages in the middle of my app, but this doesn't
seem to work properly. The destructor chain seems to be borked.
My thinking is that the destructor chain only changes when the app
launches (prior to main) and when a shared library loads and unloads. Is
this correct? If so, then the destructor chain should be valid both
before and after libraries load, right?
--
Brad Oliver
bradman@pobox.com.AM_SPAY
> My thinking is that the destructor chain only changes when the app
> launches (prior to main) and when a shared library loads and unloads. Is
> this correct? If so, then the destructor chain should be valid both
> before and after libraries load, right?
The destructor chain should be valid both before and after libraries
load, but it is not static after main starts. The destructor chain also
holds atexit registered functions, and local static destructors, e.g.:
struct X {...};
void bar();
void foo()
{
static X x; // ~X() added to destructor chain
// on first execution of foo()
atexit(bar); // bar added to destructor chain every time
}
If the runtime lib you are linking to has the file
global_destructor_chain.c, then that code fragment will have its own
independent destructor chain.
Hope this information helps.
-Howard
Brad Oliver - 27 Sep 2003 00:58 GMT
In article
<hinnant-26DDFC.18270926092003@syrcnyrdrs-01-ge0.nyroc.rr.com>,
> > My thinking is that the destructor chain only changes when the app
> > launches (prior to main) and when a shared library loads and unloads. Is
[quoted text clipped - 4 lines]
> global_destructor_chain.c, then that code fragment will have its own
> independent destructor chain.
Indeed, and that's my problem. I've got a shared library that gets
loaded, then unloaded, then loaded again by my app during the course of
execution. I was linking against the ShLib runtime instead of the DropIn
runtime. Swithing to DropIn fixed all my issues.
Apparently I had been lucky (or was unlucky but not crashing) for a long
time, and the switch to Pro 9 finally brought this issue to a head.
--
Brad Oliver
bradman@pobox.com.AM_SPAY