Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

I'm facing a strange behaviour in my windows 10 development environment.

I compile the following code (mingv gcc-8.1.0)

int main(){
    char* x = nullptr;
    std::cout<<*x<<std::endl;
    return 0;
When I run this program in a cmd or powershell window, it outputs a blank line, waits for a bunch of seconds and then returns to prompt.
I'd love to have it print "segmentation fault" and exit immediately, as god intended.
If I run the program in GDB the error is shown correctly (Thread 1 received signal SIGSEGV, Segmentation fault.).
Could someone please explain why it does this and if there is a way to obtain the desired behaviour?
Related: Why won't my code segfault on Windows 7?
                I'd love to have it print "segmentation fault" and exit immediately, as god intended. Welcome to undefined behavior land, the place god forgot about.
– NathanOliver
                Apr 13, 2021 at 14:52
                @klutt The example code is C++, but the problem is not C++ specific. I removed both C and C++ tags.
– vvigilante
                Apr 13, 2021 at 15:05
                It is not, in general, reasonable to rely on null pointer dereferences in C or C++ to produce any specific behavior, including segfaults.  This is the meaning of the "undefined" in "undefined behavior".
– John Bollinger
                Apr 13, 2021 at 15:11
                @JohnBollinger thank you for your answer. I understand, but in this specific case the compiler is generating the illegal access as expected, as we can see through the debugger; nasal daemons are not there: the segfault IS generated, just not displayed. My question is more about "why is the error hidden when I do not use a debugger? Can I change that? How? What is happening in those seconds before the prompt comes back?".
– vvigilante
                Apr 13, 2021 at 15:20
I've had the same problem and found this question when looking for an answer.
Short version, I couldn't come up with a solution by default. Instead I was able to use signal to process the SIGSEGV and print my own message. It's not great, but it's enough to notice the error and debug it.
#include <signal.h>
void segvHandler( int s ) 
  printf( "Segmentation Fault\n" );
  exit( EXIT_FAILURE );
// at the start of main
  signal( SIGSEGV, segvHandler );
Longer answer:
I'm working in an msys environment on win10.  Compiling a test application in a Command Prompt windows using the default gcc produces no fault  message when run in a command prompt but does produce a message when run in a an msys shell or in GDB.
> C:\msys64\mingw32\bin\gcc.exe --version
gcc.exe (Rev3, Built by MSYS2 project) 12.1.0
The same source compiled in an msys shell using the default gcc produces an fault message when run in the msys shell, gdb, and a Command Prompt window.
$ gcc --version
gcc (GCC) 11.3.0
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.