Paul Davis wrote:
This is occurring in a non-threaded program. I am using dlopened objects, but I'm not sharing shared_ptr's across them.
I know this code wouldn't be in boost if it weren't well tested, I was just wondering if I had happened to come up on something weird that doesn't usually pop up. I've never had a problem before, and just though I'd ask to see if this was a definitely 'my fault' sort of situation.
One problem we had in our company with shared objects (and it just occured to me that it's not relevant if you share shared_ptrs between them, the question should have been whether or not you use shared_ptrs to the same type accross DSOs), is that you might end up calling functions that are unloaded already. I'm not an expert, but I think the nature of problem was this: If you dlclose a library there might be dangling function pointers to functions within that library, if that function was a weak symbol as templates generate. The resolving of those symbols will be done at dlopening or on first use, depending on flags you give to dlopen. In either way, even though function definitions might exists in many DSOs and they're all the same, if the DSO the name has actually been resolved to is unloaded, it's a segfault if you call it, even if there is another definition of a different DSO that's still loaded. We got around it by using a lot of explicit template instantiations to reduce the number of weak symbols shared accross DSOs, and a colleague of mine wrote a link postprocessor that throws some duplicate symbols out as well. Both solutions are not very nice. Are the preconditions of this problem present in your case? Oh, and I think int is always 32bit on AMD64, though I don't know much else to say to the other branch of the thread. :) Jens