Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#1678 Crash in cout << endl

OTHER
closed
nobody
gcc-4.7.0 (11)
works-for-me
Unknown
2013-01-31
2012-11-20
Shinobu Maehara
No

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.

Discussion

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

     
  • 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]

     
    • labels: 103947 --> gcc-4.7.0
    • status: open-works-for-me --> open
     
  • 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?

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

     
    Attachments
    a.s
  • 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