I am trying to track the source of a std::exception, in basic_string::erase, I wrapped all the locations where I am calling erase directly in try/catch and am not seeing any of these catch blocks be hit, so it must be being called internally from another basic_string method. The exception appears to be the result of a race condition in the code i am working with, so it is very difficult to reproduce, any thoughts on how I could detect and or get a stack trace from this exception? btw this is c++ code on an x86 linux box.
Thank you
You should try
(gdb) catch throw
Then gdb will trigger breakpoint each time exception is thrown. You'll see a callstack.
EDIT: This post is a good bunch of tricks for debugging exceptions: GDB: How to break when a specific exception type is thrown?
Related
I have just started using c++ exceptions and want to get it right. What I have in mind is to generate some sort of backtrace information when exceptions are caught. Initially I had ideas similar to Call-stack for exceptions in C++ but eventually figured out that's not quite good.
I have also read How to generate a stacktrace when my gcc C++ app crashes but do not want to add more complexity to my current project. Since, I only need the backtracing when in debug mode, I was hoping I could be using gdb for that purpose.
My strategy has been to insert breakpoint in the catch block and then go up through the call stack to exactly pinpoint why the exception was thrown in the first place (or what caused it)? Unfortunatly, I cannot seem to be able to do this since when gdb reaches the breakpoint, it clears the call stack and I can only see main (that's where I catch). Is this supposed to happen or am I doing something wrong here?
Edit:
I just like to summarize the methods here for other folks:
1st Method (by paulsm4). Set a catchpoint via catch throw for catching on throw or catch catch for catching on catch! Then call backtrace
2nd Method (by aschepler) Set a breakpoint on __cxa_throw and then backtrace
3rd Method (in Qt Creator -- if you happen to use) You can easily set a breakpoint on throw or catch!
Edit_2: Using Qt Creator debugger, it seems that setting a breakpoint on __cxa_begin_catch is also an equivalent to catch catch :)
This this:
http://sourceware.org/gdb/onlinedocs/gdb/Set-Catchpoints.html
You can use catchpoints to cause the debugger to stop for certain
kinds of program events, such as C++ exceptions or the loading of a
shared library. Use the catch command to set a catchpoint.
So the answer should be "yes", and it should avoid the problems with the two links you cited.
Please post back if it helped! Personally, I've never tried this GDB feature myself :)
Summary of answers from the comments:
1st Method (by paulsm4). Set a catchpoint via catch throw for catching on throw or catch catch for catching on catch! Then call backtrace
2nd Method (by aschepler) Set a breakpoint on __cxa_throw and then backtrace
3rd Method (in Qt Creator -- if you happen to use) You can easily set a breakpoint on throw or catch!
Using Qt Creator debugger, it seems that setting a breakpoint on __cxa_begin_catch is also an equivalent to catch catch
I have an exception handler set up using SetUnhandledExceptionFilter, which works fine. However, if I throw an exception from within OpenMP code, I get the standard "the application crashed" window and the handler is not called -- however, I can attach a debugger just fine and see that the call stack is ending with _CxxThrowException and continues into KernelBase.dll!RaiseException. I know that an OpenMP program which throws exceptions inside the parallel regions is wrong, but I'd still like to get a crash dump. How can I get my exception handler get called in this case?
Should be possible, especially as the debugger manges to get an "Unhandled exception" window, when attached to the application after the crash (i.e. I can get a nice stack trace and stuff.) This is on Windows 7 with VC++ 2010.
(Eventually, each thread actually calls my exception handler. If it crashes, and I select 'Debug', and then continue on each unhandled exception, the handler eventually gets called and it also manages to write out a meaningful minidump. Wtf?)
Interesting. Going out on a limb, I'll wager that the OpenMP concurrency runtime doesn't honor the SetUnhandledExceptionFilter (which will work for "standard" threads), and isn't integrated into this feature of Structured Exception Handling.
Note this warning from the MSDN page on Exception Handling in the Concurrency Runtime
To prevent abnormal termination of your application, make sure that your code handles exceptions when it calls into the runtime. Also handle exceptions when you call into external code that uses the Concurrency Runtime, for example, a third-party library.
Perhaps you can try wrapping your OpenMP stuff in the style of exception handling outlined above, and then see if you can re-package and throw it (outside of OpenMP context) to get caught by the filter?
Like in Just In Time debugging, does VS 2003 compiled apps catch Win32 (or asynchronous) exceptions in a catch (...) and unwind the stack? before the dump file is written...
No, the debugger invocation is created in code that runs UP the stack from the exception, so the stack has not yet unwind. That is true for both sync (C++)and async (OS) exception.
See the Fig. 13 in the famous MSJ article A Crash Course on the Depths of Win32™ Structured Exception Handling.
The unhandled exception filter is invoked after the first pass of the exception filter list, if no filter admitted that is willing to handle the exception. This first pass is before the unwinding, which occurs on the second pass. If you break into the debugger when given a chance you'll find your exception place down your stack, and that makes perfect sense: it would give little to no value to debug a stack that had already unwound, you would have no idea what went wrong.
This depends on stack unwind semantics choosen when compiling your application
Compiler can be instructed to catch or not to catch SEH exceptions for your code.
Startup code always catches C++ & SEH exceptions and if any exception is caught it terminates the application.
I am maintaining a project which uses inter-process COM with C++. At the top level of the callee functions there are try/catch statements directly before the return back through COM. The catch converts any C++ exceptions into custom error codes that are passed back to the caller through the COM layer.
For the purpose of debugging I want to disable this try/catch, and simply let the exception cause a crash in the callee process (as would normally happen with an uncaught C++ exception). Unfortunately for me the COM boundary seems to swallow these uncaught C++ exceptions and I don't get a crash.
Is there a way to change this behaviour in COM? Ie, I want it to allow the uncaught C++ exception to cause a crash in the callee process.
I want this to happen so that I can attach a debugger and see the context in which the exception is thrown. If I simply leave our try/catch in place, and breakpoint on the catch, then the stack has already unwound, and so this is too late for me.
The original "COM masters" who wrote this application are all either unavailable or can't remember enough details.
This just in, a year and a half after the question was asked -
Raymond Chen has written a post about "How to turn off the exception handler that COM 'helpfully' wraps around your server". Seems like the ultimate answer to the question. If not for the OP, for future readers.
I don't think you can disable this behaviour, however there is a way around it if you are using Visual Studio and don't mind getting flooded in exceptions. If you go to Debug>Exceptions in VS and select "When the exception is thrown>Break into the Debugger" for C++ exceptions, it will drop into the debugger at the point the exception is thrown. Unfortunately you then get to work out which exceptions you can ignore and which ones are of interest to you.
The default setting for this is "Continue" with "If the exception is not handled" being set to "break into the debugger". If it doesn't do that already this would suggest that you'll have to find out exactly where the exceptions are being caught.
If I understand correctly, your problem is essentially the inability to get a stack trace from a C++ exception. I've never tried it myself, but it should actually be possible to get the stack trace even from within the catch block.
See: Getting an exception call stack from the catch block
The article describes the process of getting the stack trace using a debugger, but if you don't want one to be attached you can create a dump in the catch clause (one way, another), and then go through the process on your leisure.
Have a look at Vectored Exception Handlers -- depending on your exact use case, VEH could be used to intercept SEH exception handling and force crashes/dumps/whatever.
You can set up a level 2 break in debugger with sxe/sxd -c2 eh that will catch only unhandled C++ exceptions. You can also attach the debugger on the fly to your process at load time using GFlags. Of course you'd have to give up the mickey mouse debugger and use the real deal.
What you need is to enable "break when an exception is thrown" in your debugger. This way you will stop immediately when an exception is thrown and have the entire call stack at your service.
I'm using Visual C++ 2003 to debug a program remotely via TCP/IP.
I had set the Win32 exception c00000005, "Access violation," to break into the debugger when thrown. Then, I set it back to "Use parent setting." The setting for the parent, Win32 Exceptions, is to continue when the exception is thrown.
Now, when I debug the program, it breaks each time that exception is thrown, forcing me to click Continue to let it keep debugging. How do I get it to stop breaking like this?
I'd like to support Will Dean's answer
An access violation sounds like an actual bug in your code. It's not something I'd expect the underlying C/++ Runtime to be throwing and catching internally.
The 'first-chance-exceptions' feature is so you can intercept things which get 'caught' in code, using the debugger, and have a look. If there's nothing 'catching' that exception (which makes sense, why on earth would you catch and ignore access violations?), then it will trigger the debugger regardless of what options you may have set.
Is this an exception that your code would actually handle if you weren't running in the debugger?
Ctrl+Alt+E (or Debug\Exceptions)
From there you can select which exceptions break.