Hello,
I have encountered an issue when using std::ostream's that causes them to enter a fail state anytime a number is piped into them.
I have attached a minimal example project which will allow you to reproduce the issue.
The minimal example is as follows, I have a main executable that dynamically loads two shared libraries using the RTLD_DEEPBIND flag, both the main module and the shared libraries statically link against libgcc and libstdc++, and they both are built with optimization enabled.
If you do not use the RTLD_DEEPBIND flag, the issue does not occur. If you do not use optimization, the issue does not occur. The issue does not occur in the first shared library loaded but does occur in all subsequently loaded shared libraries.
Both the main module and the shared libraries are also being built with the -fPIC argument.
I originally discovered this issue using gcc-5.3.0, so I built gcc-7.3.0 and tried with that but I am still experiencing the same issue. Just for some context, I am running on CentOS 6.7 and I have also tried on CentOS 6.9.
To build the project run "make debug" or "make release" at the top level directory or individually within the different projects. The main difference between debug and release is the use of optimization.
Also, the makefiles create both x86 and x64 versions but the main module is explicitly loading the x64 versions of the shared libraries.
Within the first shared library the following code snippet outputs "Number: 5.", but in the second shared library which is identical, it outputs "Number: " and the stream enters a error state (the failbit and the badbit are set).
// OtherLibrary: shared library code snippet
void UseStreams()
{
std::ostringstream oss;
uint16_t unNumber = 5;
// note that neither the number nor the period are displayed because the stream enters an invalid state.
oss << "Number: " << unNumber << ".";
std::cout << oss.str() << std::endl;
}
I am not sure if the issue described is a bug in GCC or if there is something that I am doing wrong, but was hoping that you may be able to shine some light on what the problem may be.
Thank you for your time,
Danny Peck
