> What seems to be happening is that we register a destructor using GCC's
> __attribute__(destructor) at default priority that finalizes everything
> including calling shibresolver::term.
That I'm not real familiar with.
> One potential problem here is that we're a direct consumer of opensaml
> and so that opensaml is going to be initialized (and thus initialize
> xmltooling) both via us and via shibresolver. I wonder if that's the
> issue here.
I tried to address that by fixing things to allow additional init/term pairs, which has mostly worked as far as I knew. Either order (calling ShibResolver::term or the opensaml term()) should work, nothing happens lower down until the last paired term() is called.
I'll have a better idea or sequencing if we know what variable was being accessed.
There are mutexes created as static variables in the libraries, and they do get used during the term() calls, to address the counting of init/term, but they don't get destroyed until the runtime tears down static objects. If it's failing because of that, then the static destructors are firing first.
-- Scott
|