Re: [Boost-users] double free when both shared library and executable linked to boost libraries

Subject: Re: [Boost-users] double free when both shared library and executable linked to boost libraries
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-01-05 18:45:31

On 21/12/2014 07:45, Eric Roller wrote:
> I've run into a run-time error (double free) with my software which
> uses a plug-in architecture. The main executable (a.out) uses dlopen
> to load a shared library (mylib.so). Both a.out and mylib.so utilize
> the boost libraries (version 1.54) and are therefore linked separately
> to them. Depending on whether I use static or dynamic linking to the
> boost libraries I encounter the double free error as confirmed by
> address sanitizer using gcc 4.9.2 on linux x86_64. Here is a summary
> of the results:
>
> a.out link    mylib.so link    double free?
> static         dynamic          YES
> static         static               NO
> dynamic     dynamic          NO
> dynamic     static              NO
>
> So you can see, only when the main executable used static linking to
> boost and the shared library used dynamic linking to boost is when I
> saw the double free error at run time. My question is, why is the
> error only triggered under that condition and what is the recommended
> link configuration when using boost libraries for both a shared
> library and an executable.
>
> Ideally, the shared library plug-in should be free to use any boost
> version with either static or dynamic linking, and it should be
> independent from (i.e. not conflict with) the main executable's boost
> version and link type. What compiler/link settings would be necessary
> to achieve this, if it is even possible at all?

Provided that Boost objects appear *nowhere* in the ABI of your library 
(safest is to ensure that none of your public header files ever #include 
or forward-reference anything from Boost), you should be safe 
static-linking on both sides, or even mixing things up like above.

If Boost objects do appear in the ABI of your library, then you have to 
be more careful.  The safest option is to dynamic link on both sides. 
(You may sometimes be able to get away with static linking on both sides 
depending on which libraries you're using, particularly when they're 
header-only, but it's still not a good idea.)