I seem to remember at a previous job, when tracking down a certain bug I added a call to a function that made sure that floating point errors got reported in some way. I don't remember exactly how - probably a callback, or maybe it caused a break in Visual Studio immediately when it happened.
Tried searching for this but got nothing. Does this ring a bell for anyone? This is for a Windows game, if that matters.
(I'm not talking about enabling first-chance exceptions in Visual Studio, I want to catch it "live" as well).
It's called the floating-point environment. References:
http://en.cppreference.com/w/cpp/numeric/fenv (C++11)
http://pubs.opengroup.org/onlinepubs/009604599/basedefs/fenv.h.html (Unix)
To get exceptions to immediately halt your program, use platform-specific functions:
http://www.gnu.org/s/hello/manual/libc/Control-Functions.html (glibc)
http://msdn.microsoft.com/en-us/library/e9b52ceh.aspx (Windows)
also: http://msdn.microsoft.com/en-us/library/5z4bw5h5.aspx to get C++ exceptions; I think this is what you were after.
Related
We have a custom application we use built around VB/C++ code.
This code will run for days, weeks, months, without this throwing up an exception error.
I'm trying to learn more about how this error is thrown, and how to interpret (if you can) the error listed when an exception is thrown. I've googled some information and read the Microsoft provided error description, but I'm still stuck with the task of trouble shooting something that occurs once in a blue moon. There is no known set of interactions with the software that causes this and appears to happen randomly.
Is the first exception the root cause? Is it all the way down the stack call? Can anyone provide any insight on how to read these codes so I could interpret where I actually need to look.
Any information or guidance on reading the exception or making any use of it, and then trouble shooting it would be helpful. The test below is copied from windows log when the event was thrown.
Thanks in advance for any help.
Application: Epic.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.AccessViolationException [![enter image description here][1]][1]
at MemMap.ComBuf.IsCharAvailable(Int32)
at HMI.frmPmacStat.RefreshTimer_Elapsed(System.Object, System.Timers.ElapsedEventArgs)
at System.Timers.Timer.MyTimerCallback(System.Object)
at System.Threading.TimerQueueTimer.CallCallbackInContext(System.Object)
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext,
System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext,
System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.TimerQueueTimer.CallCallback()
at System.Threading.TimerQueueTimer.Fire()
at System.Threading.TimerQueue.FireQueuedTimerCompletion(System.Object)
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()
There are exceptions that are thrown by the c++ runtime environment, as a result of executing a throw expression, and there are other types of errors caused by the operating system or hardware trapping your instruction. Invalid access to memory is generally not thrown by code in c++, but is a side effect of evaluating an expression trying to access memory at an invalid address, resulting in the OS signaling the process, usually killing it. Because it's outside C++, it tends to be platform specific, but typical errors are:
reading a null pointer
using a pointer to an object that has been deleted
going outside an array's valid range of elements
using invalidated iterators into STL containers
Generally speaking, you can test for null and array bounds at runtime to detect the problem before it happens. Using a dangling pointer is more difficult to track down, because the time between the delete and the mis-use of that pointer can be long, and it can be difficult to find why it happened without a memory debugger, such as valgrind. Using smart pointers instead of raw pointers can help mitigate the problems of mis-managing memory, and can help avoid such errors.
Invalid iterators are subset of the general dangling pointer problem, but are common enough to be worth mentioning as their own category. Understanding your containers and which operations invalidate them is crucial, and some implementations can be compiled in "debug mode" which can help detect use of invalidated iterators.
As others have noted, this type of error is tricky to identify without digging into the code and running tests (automated or manual). The more pieces of the system you can pull out and still reproduce it, the better. Divide and conquer is your friend here.
Beyond that, it all depends how important it is for you to resolve this and how much effort you're willing to put in. There are at least three classes of tools that can help with such intermittent problems:
Application monitors that track potential errors as your application runs. These tend to slow your program significantly (10x or more slowdown). Examples include:
Microsoft's Application Verifier
Open-source and cross-platform Dr. Memory
Google's Crashpad. Unlike the previous two programs, this one requires instrumenting your code. It is also (allegedly -- haven't tried it) easier to use with helpers like Backtrace's commercial integration for analyzing Crashpad output
Google's Sanitizers - free and some are built into gcc and clang. There's also a Windows port of Address Sanitizer, but a cursory look suggests it may be a little bit of a second-class citizen.
If you can run and repro it also run it on Linux, you could use valgrind; rr (see this CppCast ep) which is a free extension for gdb that records and replays your program so you can record a debug session that crashed and then step through it to see what went wrong; and/or UndoDB and friends from Undo software, which is a more sophisticated, commercial product like rr.
Static analysis of the code. This is a set of tools that looks for common errors in your code. It generally has a low signal-to-noise ratio, so there are a lot of minor things to dig through if your run it on a large, existing project (best to start a project using these things from the beginning if possible). That said, many of the warnings are invaluable. Examples:
Most compilers have a subset of this functionality built in. If you're using Visual Studio, add /W4 /WX to your compilation flags for the C++ code to force maximum warnings, then fix all the warnings. For gcc and clang, add '-Wall -Wpedantic -Werror` to enforce no warnings.
PVS-Studio (commercial)
PC-Lint (commercial)
If you can instrument the code to write log messages, something like Debugview++ may be of assistance.
Things get harder if you have multithreading going on, which it looks like you do, because the non-determinism gets harder to track, there are new classes of possible errors that are introduced, and some of the above tools won't work well (e.g., I think rr is single-threaded only). Beyond a full IDE like Visual Studio, you'd need to go with something like Intel's Inspector (formerly Intel Thread Checker), or on Linux, Valgrind's Helgrind and DRD and ThreadSanitizer (in the sanitizers above, but also Linux only AFAIK). But hopefully this list gives you a place to start.
I am a java developer trying my hands on C-C++ code.
Basically I have some build script that uses Visual Studio components to build the application libraries - dlls. We do not use Visual Studio IDE to debug.
But whenever we face some crash in our application, we have to enter the debug statements line by line and need to check the exact line of code in which it is crashing.
Is there any API in C/C++ which would write the stack trace into a file during the crash of our program?
Some kind of event listener that would be called during a program exit and that could print the stack trace and error information into a log file.
I have seen many questions related to this but I am not able to get how to handle this in code rather than debugging tools. I feel Java is very much advanced with respect to error handling.
Thanks in advance!
The Standard does not give you any facilites for this. That said, you can use OS-specific APIs to get what you want. On windows, the easiest is probably to use StackWalker. You do need to take care of SEH oddities yourself. I suggest this article for more information.
On POSIX platforms, you can use the backtrace function from glibc.
In general, both require your program to be compiled with debug information. It is also possible to create crash dumps without symbol names (see Minidumps on Windows), but you will need to decode them (which Visual Studio does for you for example, but you mentioned in your post that you don't use it).
Also, keep in mind that writing crash dumps from a crashing process is very error-prone (since you really have no idea what state your application is at that time). You might get more reliable results if you write the crash dumps from another process. Earlier I've put together a simple example out-of-process crash handler that demonstrates how to implement that.
You can use std::set_terminate to define a function to be called when an exception leaves main() additionally you can install a signal handler for SIGSEGV to catch segmentation faults.
You can get a stack trace (on Linux) using libunwind ( http://www.nongnu.org/libunwind/ ) or use the backtrace() function from libc.
One thing I sometimes do in my own exception classes is to grab and store a stacktrace in the constructor that I can then obtain where I catch the exception and print the trace of where it was thrown from.
You could use <errno.h> in C to handle your error and log them into a log file. The standard flux for the errors is stderr.
One solution to get the error is to use the function perror included in <errno.h> that will display the exact error.
To use it, put it in an error catcher.
if (!fileIsOpen())
perror("File not opened");
I hope it helped.
The C++ projects I wrote and run without any problems on Ubuntu return the exception "vector subscript out of range" when I run them on windows. I use Windows 7 and Visual C++ 2008 Express.
I hope that makes sense to someone.
The version of the STL shipped by Microsoft comes with checked iterators, which when run in debug mode ensure that your vector indices are in range. No such checking is done in GCC by default.
Your code almost certainly contains undefined behavior. In such a case, an implementation is free to do almost anything it wants. It appears that gcc has basically ignored the problem, so it wasn't apparent. VC++ has built enough self-monitoring into your code to find the problem and tell you about it.
The next step is pretty much up to you: find the problem in your code and fix it. Unfortunately since you haven't posted any of the code, it's essentially impossible to give much more detailed advice about what you should do or how to do it. About the only hint I can think of is that the debugger in VC++ does have a nice stack trace feature, so if you run the code under the debugger and it fails, it's pretty easy to walk back up the stack to find the code that called the function (that called the function, etc.) where the problem was detected.
I've configured Visual Studio to throw floating point exceptions via the _controlfp function. This works for NAN and INF, but not QNAN. I.e. Quiet NaNs don't cause an exception to be raised. Is there any function, or config option for Visual Studio 2008/2010, that will force QNANs to instead be NANs, so that they throw exceptions?
Some helpful tips, although I've never even remotely done something like this:
Read: http://www.cisl.ucar.edu/docs/trap.error/errortypes.html
The resulting search on the internet (which I've really only spent about 30 seconds on), leads me to believe that this is normally enabled with a compiler option.
However, I also seem to recall that such enabling/disabling of traps can be specified programmatically, and especially in windows, this can be done by pretty much any program, such as when a printer is used for printing. Additionally, if you change this option programmatically, please set it back to the previous value as soon as you can, otherwise if people from .NET try to use your code, they might have issues.
(In other words, your use of _controlfp could be overriden by some other routine, assuming that is indeed the correct approach to use)
Also see Visual Studio C++ 2008 / 2010 - break on float NaN
I've recently implemented some vectored exception handling to catch errors in our software. This is especially useful as we've just converted from vc6 to vs2005. We're encountering a few problems with the use of the STL library (generally people doing things they shouldn't). I'm trying to catch these errors with my vectored exception handler.
However this doesn't seem to get called, instead these errors are internally processed by the Microsoft Visual Studio C Runtime library.
My question is;
Is there a way to turn off the runtime error checking and get the exceptions passed to the VE handler?
Thanks
Rich
http://msdn.microsoft.com/en-us/library/aa985973%28VS.80%29.aspx
#define _SECURE_SCL 1
#define _SECURE_SCL_THROWS 1
The above allows me to throw exceptions.
You can turn off the additional run-time checks. However, not all errors this catches will result in a crash which you can intercept.
On a sidenote: These checks often consume significant performance and are, by default, not turned off in release builds.
#define _SECURE_SCL 0
It's best to do this via project settings, as you could get nasty linker problems if the setting differs within or between files.
I ran into this problem a while ago and it took me some time to wrap my head around what they are doing in their runtime. I would recommend reading "Migrating from Previous Versions of Visual C++" on MSDN at least twice. Then read "Extensions to the C Library, Part I: Bounds-checking interfaces (ISO/IEC TR 24731-1)". The latter is the standard that most of the parameter checking stuff is based on.
Once you understand what they are up to, just define _CRT_SECURE_NO_DEPRECATE, _SECURE_SCL, and _SECURE_SCL_THROWS in your project settings. Then make sure that you have "Enable C++ Exceptions" set to "Yes with SEH Exceptions (/EHa)" and "Basic Runtime Checks" set to "Default" in your project. At least, that is what is working for us right now. It did take some time to remove the incorrect code that we had created under VC6 though.
The most important thing that you can do is set aside a few weeks and really dig into what the various options and macros do. Then figure out what works with your code. We didn't do this early enough and it hurt a lot once we had some "bad builds" make it out of engineering.