std::endl crashes Windows 8, compiled using MinGW

Question

I have 3 computers, two of which use Windows 8. Using the latest version of MinGW's g++ (4.8.1-4) my hello world program freezes whenever I compile and run on the Windows 8 computers but not in Windows 7.

#include <iostream>
int main()
{
    std::cout << "Hello, World!" <<std::endl;
    return 0;
}

This compiles just fine in g++ but running a.exe will display "Hello, World!" then a window will pop up and say "a.exe has stopped working, Windows can check online for a solution to the program...." etc.

Has anybody seen this problem.

Also, I tried "std::cout << "Hello, World!\n" << std::flush;" and this has the same problem. It seems that every function that flushes the buffer causes a crash.

Following Eric's advice, I recompiled the program and ran it in gdb and got the following output:

Program received signal SIGILL, Illegal instruction. 
0x00405065 in _Jv_RegisterClasses ()

Underage

Try running under a debugger; it will at least tell you where the failure is. – Jailbird

OK, I ran gdb and it says "Program received signal SIGILL, Illegal instruction. 0x00405065 in _Jv_RegisterClasses ()" – Underage

I'd think the most likely cause is that the standard C++ library is compiled with an incompatible version of some run-time loaded library, most like some fundamental library. – Bozarth

Sorry about previous comment, I somehow skipped the last line of your question. Eric's suggestion seems the best for now. Check the whole stacktrace, if it's obscure or hard to read, post it here, we'll help. Also, checking the console's encoding/codepage could help too, but I can't see how it could crash the app. At worst, it should just output strange symbols instead of text. – Cardona

Try std::cout << "Hello, World!\r\n" << std::flush; (and disable unicode) – Montgomery

_Jv_RegisterClasses() is start-up code that runs before main - was the output displayed in the debugger execution? If not, perhaps a different problem? What compiler options were you using? – Burlington

Host Win8 or Win8.1, 64bit or 32? If Win64 are you using MinGW or MinGW-W64? If MinGW-W64, did you build for 32bit to 64 bit target? – Burlington

@Clifford, yes, the output was displayed in the debugger execution. to Clifford again, I'm running 32 bit windows with 32 bit MinGW building for (i assume) 32 bits. Actually, my win 7 computer is 64 bits but I'm running everything as 32 bits. – Underage

Perhaps same as issue at #14368982, where the solution was to avoid DLL runtime libraries by specifying -static-libgcc -static-libstdc++ – Burlington

Answer 1

In the second instance, the '\n' should cause an output flush in any case, although in Windows I believe console output is immediate (or perhaps automatic after a short timeout) in any case without an explicit flush.

I suggest the following experiments:

1) See if it is specific to the C++ library by using the C library (in MinGW Microsoft's C runtime is used rather than glibc):

#include <stdio.h>
int main()
{
    printf( "Hello, World!\n" ) ;
    return 0;
}

2) Eliminate the exit code by:

int main()
{
    return 0;
}

3) No newline at all:

#include <iostream>
int main()
{
    std::cout << "Hello, World! ;
    return 0;
}

4) Try different compiler options such as optimisation levels, or -fno-builtin for example, or as suggested here: -static-libgcc -static-libstdc++ (although I doubt ``-static-libgcc` will itself have any effect since MinGW uses Microsoft's C runtime DLL and the static library is only available with Microsoft's tools).

Burlington

This worked. you were right about -static-libgcc flag not helping; only the -static-libstdc++ flag was able to solve the problem. Also, -fno-builtin also didn't fix it. I'm a fairly experienced python programmer but obviously I'm just learning c++ right now. Would you mind making a guess as to what exactly this compiler flag did to solve my problem? – Underage

@user1276560: Without -static-libstdc++ the standard C++ library will have been provided by a Dynamic Link Library rather than a statically linked library. There is presumably some incompatibility in the MinGW build of that library, that does not exist in the static library build. You may find that as a result your executable is a little larger, but on the plus side, it will be re-distributable without having to ensure the DLL is distributed with it. – Burlington

@viveksinghggits : That is not how SO works. If you have a question, post a question. Comments are not suited to this purpose, and the only audience you are likely to get for your comment is me and anyone else who commented on this specific answer. SO is not a discussion forum. Morever this answer is over two years old! Code can crash for any number of reasons; it is very unlikely that the cause of yours is in any way related to this question. – Burlington

Answer 2

I had the same issue and found after a long painful search that I had multiple versions of the mingw provided libstdc++-6.dll on my computer. One was part of the mingw installation the others were part of other installation packages (gnuplot and GIMP). As I had gnuplot in my PATH the compiled mingw exe it would use an older, incompatible version of this dll and crash with the described symptoms. I can, therefore, confirm Dietmar Kühl's suspicion. As suggested above linking the library statically obviously helps in this case as the library functions are included in the exe at compile time.

Vic

This is not the answer. The question was answered 3 years ago, so why did you post an answer which you know does not solve the problem? – Gordon