Menu
▾
▴
#1678 Crash in cout << endl
When I compile the following pogram;
========[ endl.cpp ]========
#include <iostream>
int main()
{
std::cout << "X" << std::endl;
return 0;
}
========[ eof ]========
With: g++ endl.cpp
The resulting program crashes because cout << endl tries to execute "X" as if it were code, which it isn't, it's a char const *.
Details:
The first << executes correctly and is:
std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)
It displays an X on the terminal.
The next << is the one that fails and is:
std::ostream::operator<<(std::ostream& (*)(std::ostream&))
It performs a jmp to an address in the data section, to be precise the location where "X" is stored.
OS: Win7
$ gcc -v
Ingebouwde specs worden gebruikt.
COLLECT_GCC=C:\MinGW\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.7.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.7.2/configure --enable-languages=c,c++,ada,fortran,obj
c,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgo
mp --disable-win32-registry --enable-libstdcxx-debug --disable-build-poststage1-
with-cxx --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
Thread model: win32
gcc versie 4.7.2 (GCC)
$ ld -v
GNU ld (GNU Binutils) 2.23.1
$ uname -a
MINGW32_NT-6.1 COMPUTERNAME 1.0.17(0.48/3/2) 2011-04-24 23:39 i686 Msys
I updated MinGW today, so I believe I'm running the latest version, and the minimal test case above is just your basic hello world type program so I believe this is a bug.
WJFFM. I upgraded both GCC/G++ and binutils to current versions and your test program executes without displaying errors.
You showed the GCC version but not the version of G++, they might be different.
Just now I uninstalled MinGW and installed the 4.6.2 version and the problem appears to be absent in 4.6.2. In that version, the second << call doesn't jump to "X" but to:
std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&)
Which is a thunk to:
libstdc++-6!_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
Two further remarks:
1) The MinGW uninstall command didn't work, I had to manually delete the files in C:\MinGW otherwise the install would fail.
2) There is really no need for the thunk. Rather than this sequence:
call thunk
jmp [import]
The following should be used:
call [import]
I ran the uninstaller again and cleaned out C:\MinGW again and installed 4.7.2 again. I did this using the official installer and by then opting for the most recent version (rather than the pre-packaged 4.6.2 version.
The problem manifests itself again.
Note that this problem shouldn't depend on hardware or operating system configuration, since the problem is that a wrong executable is generated which will fail regardless of where it is run. I have also through the power of Google discovered that I am not the only one who stumbled upon this problem.
$ g++ --version
g++.exe (GCC) 4.7.2
Copyright c 2012 Free Software Foundation, Inc.
Dit is vrije software; zie de broncode voor kopieercondities. Er is GEEN
garantie; zelfs niet voor VERKOOPBAARHEID of GESCHIKTHEID voor een bepaald
doel.
Questions:
1) Is your install the vanilla install?
2) Are you sure it doesn't crash? If WER is turned off or something you may not notice if it does since in this case the only difference would be a missing blank line.
3) Does in your case the second << call jump to the stub rather than the data section?
4) Is there an easy way to compare our setups without sending ~ 300 MB down the wire?
5) Is there any other way I can help you diagnose this?
As I stated already WJFFM.
I have an I7 CPU laptop with 8 cores. I use mingw-get on the command line and execute within the MSYS console.
To ensure it isn't a 64bit to 32bit issue I start /c/windows/sysnative/cmd.exe and in the new window execute the binary without issue.
I've attached the temporary assembler file from the build process. You'll see that there is no jmp in it.
Assembler file processed from the OP's test program.