hidden visibility and statics

Jonathan Wakely jwakely.gcc@gmail.com
Fri Mar 2 12:39:00 GMT 2018

On 2 March 2018 at 10:31, Kilger, Kilian wrote:
> Hi,
> I have a problem with a relatively old version of libstdc++, but this is more concerned with the compiler (or linker?) itself and might still be relevant.
> In this version of libstdc++ (the version shipping with 4.8.5) the std::string class has a static member for the empty string. Before freeing the string,
> the code checks if the string equals the empty string, because this must not be freed.
> This doesn't work, if there are multiple shared libraries involved and the string is passed from one .so to another .so. If -fvisibility=hidden is on, then it seems that
> there are multiple "instances" of the static active in the different shared libraries. So, in the context of the called shared library, the string does not equal the empty string (of this shared lib)
> anymore and he tries to free it, resulting in a core dump.
>   1.  Why does this happen with "-fvisibility=hidden"?
>   2.  Is there some mechanism to prevent that?
> We use gcc 4.8.5 as this is still used in some major enterprise distributions. The problem seems to be gone in newer gcc versions, probably due to changes in libstdc++.

It still happens if you select the old std::string implementation, via

This seems to be the same issue as

I think the library should be ensuring the empty string rep is always
visible, even if you use -fvisibility=hidden.

> A small demo program reproducing this problem can be found here:
> https://github.com/cohomology/gcc_string_problem
> Best regards,
> Kilian.

More information about the Gcc-help mailing list