Re: [Boost-users] shared_ptr segfaults on 64bit AMD

From: Jens Theisen (jens-theisen-tmp01_at_[hidden])
Date: 2006-08-27 13:10:54

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