Re: hidden visibility and statics

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
-D_GLIBCXX_USE_CXX11_ABI=0

This seems to be the same issue as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78747

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.
>



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux