https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67903
Bug ID: 67903
Summary: std::locale compatibility between gcc4.9 and gcc5.1
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ylow at graphlab dot com
Target Milestone: ---
Created attachment 36466
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36466&action=edit
patch to locale.cc
This is a complex issue and is probably an artifact of how we are doing our
linking. In general, I am not entirely confident of my diagnosis and it is hard
to replicate in a smaller test case.
In our code, we statically link libstdc++ into our shared library since that
resolves a lot of issues with dynamic libstdc++ since a different (older)
libstdc++ may be loaded before us.
However, there is some kind of conflict in std::locale static initialization
when:
- There is a system libstdc++ from gcc 5.1 (i.e. a newer libstdc++)
which creates a lot more facets
- The system libstdc++ first (and initializes it)
- Then our shared library loads and the following occurs:
- std::locale::_S_initialize_once() is called again.
This is probably due to _S_once not being exported so
so every occurance of the libstdc++ initializes again.
- However, the local init implementation IS exported
- So the new init function is called,
- However, _S_global is NOT exported
- So the old object is used.
So to summarize,
- We have a repeat initialization of std::locale. Once in the new libstdc++
and once in the old libstdc++ (this is actually OK)
- However, the new locale function initialization is used always which
causes issues since in gcc 5.1, the locale has more stuff: It fills 46 locales
into _M_facets rather than 28.
This would not be a problem if not for the fact that:
- the global locale is initialized with an inplace new:
locale_init.cc:378
_M_facets = new (&facet_vec) const facet*[_M_facets_size];
_M_caches = new (&cache_vec) const facet*[_M_facets_size];
- the locale inserter (locale_init.cc:354) correctly checks when it should
extend the _M_facets, but happily just deletes the old array.
locale.cc:348
delete [] __oldf;
delete [] __oldc;
- which of course fails gloriously with the inplace new.
- The solution is to actually do the resize correctly and check when we
do not actually need to delete.
The attached patch does fix the problem.
