Jens Theisen wrote:
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
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
I don't believe this is the situation. The DSO's I use are loaded durring the program initialization. (I load them in my code, but they're all loaded before anything gets called) And each DSO is used as single use type of thing. Basically, each one has a method called run() that gets executed. And not to mention, the segfault happens inside the DSO. Ie, it happens durring the call to run(). So no, I don't think this is my issue. Although it is quite an interesting issue that I'll have to keep in mind in the future. Thanks, Paul