#1678 Crash in cout << endl

gcc-4.7.0 (11)

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

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


  • Earnie Boyd

    Earnie Boyd - 2012-11-20
    • labels: 3262062 --> 103947
    • status: open --> open-works-for-me
  • Earnie Boyd

    Earnie Boyd - 2012-11-20

    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.

  • Shinobu Maehara

    Shinobu Maehara - 2012-11-20

    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:

    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]

  • Shinobu Maehara

    Shinobu Maehara - 2012-11-20
    • labels: 103947 --> gcc-4.7.0
    • status: open-works-for-me --> open
  • Shinobu Maehara

    Shinobu Maehara - 2012-11-20

    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

    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?

  • Earnie Boyd

    Earnie Boyd - 2012-11-20

    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.

  • Earnie Boyd

    Earnie Boyd - 2012-11-20
    • status: open --> open-works-for-me
  • Earnie Boyd

    Earnie Boyd - 2012-11-20

    Assembler file processed from the OP's test program.

  • Earnie Boyd

    Earnie Boyd - 2013-01-08
    • status: open-works-for-me --> closed-works-for-me
  • Earnie Boyd

    Earnie Boyd - 2013-01-31
    • status: closed-works-for-me --> closed
    • resolution: --> works-for-me
    • category: --> Unknown
    • milestone: --> OTHER

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks