As I have the choice on finalizing a project to keep assertions, I'd think that assertion violation would be shown or displayed on console (hopefully on stderr on linux). What would be the proper way to do such, like seems that I have to add it or enable something to get it...
You don't have to do anything additional (at least, I've never had to). The assertion violation will result in a stack trace to stderr.
Related
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?
I have a bad application raising an access violation on windows. This pops up the "crash dialog" on windows and I don't want that to appear on the user's computers. On Linux, I would install a signal handler for SIGSEGV, and just exit() in the sighandler function, but I am on Windows, and I know close to nothing of the Windows API.
As far as I understand, Windows throws an exception ACCESS_VIOLATION when a segfault happens. I assume it's a regular C++ exception and one can catch it, but the program I need to patch is in C, not C++. How does one install a "signal handler" on windows? (assuming the concept of signal exists, considering that signal() and friends are a POSIX API)? Is this API implemented as a core API, or is it part of a POSIX compatibility layer that may not be present on a vanilla deployment?
I am working with VS2008 on Win7
It's not1 a "regular C++ exception". It's an OS trap.
On Linux and other Unix-like systems, OS traps are called "signals".
On Windows, they are called "Structured Exceptions". You'll find a ton on information online about SEH, which stands for structured exception handling. The official documentation is on MSDN
Windows C and C++ compilers have special keywords for working with structured exceptions
__try {
}
__except( MyExceptionFilter(GetExceptionCode(), GetExceptionInfo()) ) {
}
Inside the exception filter, you can inspect the exception code and discriminate between access violations, divide by zero, floating point signals, etc. You can find out where the exception happened and log a stack trace (with some extra work). And you can choose whether or not the handler code block runs.
Underneath, these keywords get translated into code that sets up trap handlers, using data structures like vectored exception handler tables. But you really want the compiler's help rather than doing it yourself. Seeing the internal implementation is only of interest to compiler developers or if something goes wrong and you have to debug through it.
1Depending on your compile options, in Visual C++ it's the /EHa and /EHs options, C++ exceptions might be built on top of SEH (there's one particular exception code which means "Microsoft C++ exception", and a pointer to the C++ exception object is stored in the SEH parameters). When that happens, stack unwinding of C++ try/catch and SEH __try/__except/__finally is unified -- both exceptions unwind through both handler styles. The __set_se_translator function is also interesting to people using both C++ exception and SEH in the same program.
Situation:
I am working on upgrading some code at my work place. The code is for a process that is based off of GMime. We currently use GMime 2.2 and I recently upgraded our code to use GMime 2.4. The proces runs just fine and doesn't crash, but I get a
GLib-GObject-CRITICAL **: g_object_unref: assertion G_IS_OBJECT (object)' failed
every now and then when the program is running.
There are times that calls to g_object_unref fails and crashes my program. I'm trying to debug this, but unfortunately the person who made this program didn't add any testing or debugging features.
I know and understand how important embedding debugging information or setting up a testing framework is, when you have to go back into old code. I know how to set this up in pure C or pure C++, but as soon as other libararies get tossed in it becomes really difficult.
My problem is:
How how do I effectively setup debug code and/or a testing system with a program that relies on GLib or GObject?
My questions are:
How can I tell what's happening in the code? Should I be listening for "signals"? How do I setup those signals?
Functions like g_object_unref return void. That being the case how do I output debugging information related to these functions?
Does a GObject have a "property/class member", I don't know the proper term for this in relation to GLib, that has error information embedded in it?
(Related, but slightly off topic) Libraries like GLib and node.js ecetera have "extensive" documentation that amounts to:
function doSomethingThatShouldBeUsefulAndUnderstoodByAnyoneWhoReadsThis(WYSIWYG, FIY, BYOF, X, Y, Z) // this function does something that should be usefull and understood by anyone who reads the function this does something and can be called
How does one has a lot of programming experience (with languages in their pure form), go about making heads or tails of the library when most tutorials refer you back to the documents or are the documents themselves?
Is there a recommended tutorial for this?
Sites I have looked at:
http://arunchaganty.wordpress.com/2008/05/18/i-am-a-gobject/
create and emit gtk signal
https://developer.gnome.org/glib/2.28/glib-running.html
https://developer.gnome.org/gtk-tutorial/2.90/a2901.html
https://developer.gnome.org/gobject/unstable/gobject-Signals.html
Any and all comments, questions and suggestions are greatly appreciated!
Thank you.
The easiest way I know of to debug issues like this is to run the program under a debugger and break on g_logv (that error message was printed with g_logv) and when the debugger catches a call to g_logv, you can get a backtrace to see where in your program you are.
Usually these types of errors happen when a programmer tries to call g_object_unref() on a NULL pointer.
That said, is there a reason you only upgraded to GMime 2.4 instead of GMime 2.6? 2.6 has been out for several years now and is the series that is best maintained.
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.
I'm debugging a program written in plain C (no C++, MFC, .NET, etc.) to the WIN32API. It must compile in both VS2005 (to run under Win 2K/XP) and VS2010 (to run under Win7.) I've been unable to duplicate a bug that my customer seems able to duplicate fairly reliably, so I'm looking for ways to have my program "debug itself" as-it-were. It is monitoring all of the key values that are changing, but what I'd really like to see is a stack dump when a value changes. Oh, I cannot run a "true" debug build (using the debug libraries) without installing the compiler on the customer's machine and that is not an option, so this must be built into my release build.
Is there any way to do this other than just adding my own function entry/exit calls to my own stack monitor? I'd especially like to be able to set a hardware breakpoint when a specific memory address changes unexpectedly (so I'd need to be able to disable/enable it around the few EXPECTED change locations.) Is this possible? In a Windows program?
I'd prefer something that doesn't require changing several thousand lines of code, if possible. And yes, I'm very underprivileged when it comes to development tools -- I consider myself lucky to have a pro version of the Visual Studio IDEs.
--edit--
In addition to the excellent answers provided below, I've found some info about using hardware breakpoints in your own code at http://www.codereversing.com/blog/?p=76. I think it was written with the idea of hacking other programs, but it looks like it might work find for my needs, allowing me to create a mini dump when an unexpected location writes to a variable. That would be cool and really useful, especially if I can generalize it. Thanks for the answers, now I'm off to see what I can create using all this new information!
You can use MiniDumpWriteDump function which creates a dump, which can be used for post-mortem debugging. In the case application crashes, you can call MiniDumpWriteDump from unhandled exception handler set by SetUnhandledExceptionFilter. If the bug you are talking about is not crash, you can call MiniDumpWriteDump from any place of the program, when some unexpected situation is detected. More about crash dumps and post-mortem debugging here: http://www.codeproject.com/Articles/1934/Post-Mortem-Debugging-Your-Application-with-Minidu
The main idea in this technique is that mini dump files produced on a client site are sent to developer, they can be debugged - threads, stack and variables information is available (with obvious restrictions caused by code optimizations).
There are a bunch of Win32 functions in dbghelp32.dll that can be used to produce a stack trace for a given thread: for an example of this see this code.
You can also look up the StackWalk64() and related functions on MSDN.
To get useful information out, you should turn on PDB file generation in the compiler for your release build: if you set up your installer so that on the customer's computer the PDB files are in the same place as the DLL, then you can get an intelligible stack trace out with function names, etc. Without that, you'll just get DLL names and hex addresses for functions.
I'm not sure how practical it would be to set up hardware breakpoints: you could write some sort of debugger that uses the Win32 debugging API, but that's probably more trouble than its worth.
If you can add limited instrumentation to raise an identifiable exception when the symptom recurs, you can use Process Dumper to generate a full process dump on any instance of that exception.
I find I cite this tool very frequently, it's a real godsend for hard-to-debug production problems but seems little-known.