When running a program I've written in C, which contains a bug that causes a crash, I'll get the following message from Windows:
A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available.
This doesn't help me at all to find the problem. It can be an array out-of-bounds bug which causes a segfault, or a NULL-pointer dereference, or anything else.
At the end, I find the error by commenting-out code until the rouge code is found.
I'd like to have a faster way to track down these bugs. Is this possible with "Vanilla" Mingw GCC and Windows? Or do I have to install a fancy IDE to get meaningful error messages after crashes?
Related
Firstly, I'm a novice.
Secondly, I once ran a C program that tries to modify an OOB array element. I did it in my browser and the website handled the segmentation fault without damaging the environment.
But I'm afraid to do the same thing on my laptop as it might break stuff or corrupt pieces of data.
So, how can I make these kind of grave mistakes in C without damaging my PC or crying afterwords?
Any kind of solution will be considered: VM or whatever.
Lastly, thanks.
Do not worry! Modern os protects you! When a segmentation fault happens, it is a signal from the memory management unit, saying: this is not your memory, you are trying to read/write/execute. It will interrupt your program before anything can happen. If you look deeper into how memory works, you will see that nothing can happen, because memory pages of other processes are not mapped to your process. But there is a scary thing. If you write to memory of your process, where you don't want to write, but you are allowed to, weird things will happen. But don't worry, usually they wont do anything are are even detected by your os (stack smashing).
Also if you are using Windows 95 or some other weird thing, you have to be careful, because some old os allow you to write to your text segments (the loaded code).
An exception is the so called kernel space. There anything can happen.
EDIT:
I am not saying it is ok to make your programs crash in a segmentation fault in production. I want to say that it is not harmful for your machine.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 4 years ago.
Improve this question
If the C code is run on windows machine using visual studio, the segmentation doesnt show up and the output is also as expected.
Note: There is lot of usage of pointers in the code for memory allocation and deallocation. The depth of usage of pointers is high (upto 3 levels).
What could be the problem?? The debugging of C code in gdb is also very difficult as it just shows which function is throwing the seg fault and not the line in the code.
You haven't really provided enough information. People here will need more information, to be able to help you. I will update the answer if more details are available.
This is pretty much you can do as of now.
Try to narrow down the problem, and post it here. Certainly, you have limited experience with C, which is okay. But while you may not realise, the details you have given about your program, like "lot of usage" of pointers, or "pointer of pointer of pointer"(3 level), etc, apply to each and every real world C program. Look for the functions where you see segfault.
Are you sure about your conclusion of it works on windows, but not linux. Or it's just an intermittent failure(works/fails sometimes randomly). Try running it multiple times with different inputs(if possible) on both windows & linux to be sure.
Post some details like which compiler you are using on Windows vs Linux. In my experience, I have seen string allocations working differently with different compilers.
Try to post a reproducible piece of code if possible, a small piece of code from your program, that can run independently, and shows similar error. Or at least post the section of code and stack trace of the seg fault. That is how people will have most probability to be able to help you.
If your program is generating a core file on segmentation fault, learn about how to analyse it using gdb, if you haven't done it already. It provides pretty detailed information. In case core file is not getting generated, or it's incomplete/corrupted. Run ulimit -c unlimited on terminal before starting your program, or put this line in ~/.bashrc file.
Learn how to use valgrind. Run your program with valgrind, and see if the generated report shows and invalid reads or invalid writes. Rule of thumb is, you shouldn't be having any of those, unless you are absolutely sure, after getting reviewed, that it's there for a reason. Most of the times, there is always a better way to avoid it. Any such error will either lead you to your issue, or another future issue.
I have a double free that I'm trying to hunt down. It got introduced in an edge case long ago, far enough back that I can't easily bisect to find what introduced it. So the next best way to hunt it down would be to debug it. I tried to find any documentation indicating whether Valgrind's gdb server could be configured to break on any violation. This would be desirable so I could understand the context of the second free. (Hopefully the invalid free is the second one).
Valgrind activates by default its embedded gdbserver. This allows a GDB to connect to it at any moment.
If you want Valgrind gdbserver to stop and wait for a connection from GDB when an error is detected, you can use the option --vgdb-error=<number>
By specifying --vgdb-error=1, valgrind will stop at the first error detected, and all the following errors.
See http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver for more details
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 7 years ago.
Improve this question
TL;DR Program works on one system. On home system it hangs before reaching the main entry point (checked with debugger).
I have a local repository of code for a group project, synced up to the latest version that I have tested on several other machines (including Linux, Windows and Macs) that I am sure will work without giving any nasty errors. It's a fairly straightforward program, the main technical challenge we've dealt with has been linking in SDL2, which has been fairly easy.
The program compiles perfectly on my local machine and throws no warnings or errors even with as many of the warning flags turned on as possible. I've made sure that I'm not accidentally using .o files from a different system and I've cleaned then recompiled the code several times. I've reverted my local repository back to older code from the project that I'm also sure previously compiled and ran on my local machine.
I've made sure that the linking in of external libraries in gcc is working correctly, and there are no warnings or errors coming from that. The final linking together of the .o files is also error and warning free.
I've re-installed all the relevant .DLLs (in this case, the only DLL is the SDL one) for the program I'm working, both in the logical system locations and the working directory of the compiled executables. I've made sure that the .DLLs are the correct bit versions, and even tried the wrong bit versions in case I was accidentally making a version that needed the other bit versions.
I've re-installed my compiler (which I'm getting from Msys2 at the moment), and I've tried using the compiler that comes from Mingw64 instead.
None of these things have made any difference. When I go to run the executable, nothing will happen. No process is created and any terminal window which I'm running it from will just hang until I force close it (it won't respond to ctrl-c).
If I try running it in debug mode, gdb will be able to open the executable, and give me all the information, but once I try to run it, it will hang just like the terminal windows. Even if I try to break it at the entry point, the program seems to never get to the entry point, because it still hangs.
This problem started completely randomly. I came home from my university, having been working on the code before I went to university that day and having left it in a compilable state, came home, hit make and it wouldn't run. This was even before I had pulled the changes that we had committed and pushed that day, which is why I'm completely lost as to exactly why this will compile so happily yet absolutely refuse to run in any conditions.
If the debugger doesn't reach the main entry point, then the most likely culprit I can think of is static initialization fiasco, which is consistent with the behavior you describe: works on one system, fails on another.
Without seeing any code, we are just throwing arrows in the dark.
C vs C++:
Static initialization fiasco applies to C++ only, but keep in mind that libraries, even libraries linked to a C program can contain C++ code (not necessarily exposed as an interface).
Be sure to check Is there any way a C/C++ program can crash before main()? .
#JohnBollinger had an excellent comment: check if a simple program (compiled with the same compiler & flags) runs. We sometime get absorbed on where we think the problem is, that we can easily miss things like this.
Another thing you can do is to use ldd to see if the correct libraries are linked to your program.
I have a C CLI program that crashes and generates this error in Windows 7:
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
First, I read somewhere that it could be caused assert statements triggering so as a first measure I replaced them with if statements to catch and log any potential failed asserts. Second, I sprayed the code with printf statements to see where the program exits. Third, I especially made sure that the code doesn't exit anywhere without first logging the exit. The program is threaded so there are quite a few things going on, but nothing too complex.
Now the problem is that the second time I got the error it showed that the program exited outside of my printf statements so I can't tell where it exited.
So two questions:
I suspect I would need to use a proper debugger to see more details regarding the exit, if so, which one?
Are there any other gotchas regarding this sort of error besides the assert statements? I find quite a few C++ blog entries regarding this error, but not too many C ones.
I am using Visual C++ 2008 Express Edition. Also, I am invoking the program in CMD.exe.
First of all, you removed calls to assert which are typically meant to help track down cases where the assumption the programmer makes don't hold? Really? Uhm...
Second of all, are you familiar with the debugger at all? Visual C++ should include an integrated debugger that can, when your program runs in debug mode, not only show you where your process exits from but it can also show you exactly where your program crashes, how it got to that point and what the values of variables where at the time of the crash. Imagine that!
This article mostly talks about C# but the principles are the same.
The message you are getting is from the VC runtime. It happens when an exception is thrown and not caught anywhere.
Compile your program with a debugging debugging configuration (that should be the default) and run in the debugger, and when you hit an unhandled exception, the debugger will break. Under the "Debug" menu, you will find an "Exceptions" item, which will help you fine tune how the debugger responds to exceptions.
Note that in the context of C++ and Windows, 'exception' can mean one of several things; there are the Win32 exceptions, the C++ exception, and VS Structured Exception Handling.
assertions are for fail conditions that you never expect to happen, but can't prove can't happen. You should always be surprised by an assertion. Many (most? all?) implementations of assert() are only compiled in debug configurations and not release configurations.