I am using the GHS MULTI Debugger to debug an integrity project for an embedded application. Does anyone know how to configure a stop on throw for this debugger like you can do in GDB? I want to have it break when an exception is thrown. (I know the majority of SO does not develop Integrity projects or use the MULTI debugger, but I thought I would throw this out there to see if any other Integrity developers might know).
For this example let's assume your Integrity project is named Test.gpj.
Before compiling your code, edit your Test.int file in a text editor and change the "StartIt" value to false. This will prevent the executable from starting immediately when it is loaded.
Then in the simulator (or on the target), when you load your executable, start debugging it with the Test_as0 file.
In the Multi Command line, enter:
e __throw
Set a breakpoint on the beginning of this function (set the breakpoint to be an any task break point).
Repeat this also for the __rethrow function.
Now, when an unhandled exception occurs when your executable is running, it will hit one of these break points. You can then navigate the call stack and see where this exception is occurring. (There is an option in the Debugger GUI to navigate up and down the stack frames). Alternatively you can enter:
Ctrl + + and Ctrl + - will navigate up and down the stack frames to find where the exception was encountered.
Related
Using UI Automation for some Windows I get the following exceptions on a IUIAutomationElement::FindAll() call using VS2017. First question, what is a wil:ResultException and what does it mean it rethrow at memory address 0? I check the FindAll() result and doesn't seem to have FAILED(hr) because it outputs a debug message if it did and it's not.
Exception thrown at 0x00007FF897AC3E49 in app.exe: Microsoft C++ exception: wil::ResultException at memory location 0x000000550AF2BDC0.
Exception thrown at 0x00007FF897AC3E49 in app.exe: Microsoft C++ exception: [rethrow] at memory location 0x0000000000000000.
I don't know if it is related or not. I turned on the fairly new "Use Text cursor indicator" as users are telling us our app can crash when it is on. After doing some testing, I was closing the app and got an access violation deep in UIAutomation.dll. The system was just exiting the process. I was trying to duplicate the crash and though I didn't crash, I just saw this same message and the reply to this post that mentioned UIAutomation. The "fairly" new setting is new to me because our IT just allowed the version update that has the setting on our boxes.
The crash occurred while doing a PeekMessage during the exit of the process. We had a static c++ object that was being deleted and during that call, it called the API. I rearranged the code to make the call that used PeekMessage so it happened before the process exited. That avoided that crash. However, we are MFC based and in a debug build, if any code does an ASSERT during shutdown, MFC's assert code does a PeekMessage to remove WM_QUIT before showing the assert message box. So, we can still crash there randomly in our debug builds.
When running with the Text Cursor Indicator on, I see a lot of these "wil" exceptions in the debug output window (release or debug builds). Many seem to occur when a window that has the indicator drawn over it closes. Example - standard file open dialog. I open it, click the path edit box and when I close the dialog, I get some of those exceptions. Turning off the indicator setting avoids all of that and the crashes.
When I testing my code with OCUnit, it makes exception log and makes it fail, but never stop when the exception raises. Even the breakpoint doesn't work.
I want to track the stack and see the state at the time of exception, but debugger doesn't pop up. How can I debug test code like regular code?
Set an exception breakpoint on the project.
Go to the Breakpoint tab on the left pane of XCode. It looks like an arrow pointing Right.
Then at the bottom of that screen click the + and Add Exception Breakpoint...
I have a piece of code in C# that's essentially like the following...
WriteFile();
try {
RunTest();
} finally {
DeleteFile();
}
Now this has been planned so that even on failure, it cleans up the files it left behind. This works when not run in debug mode (although it pops up a message asking if I want to debug the program or close it. Closing it produces the appropriate results).
When I run this in debug mode and hit an exception inside of RunTest, I only seem to have two options. In the first one, I tell debugging to stop. This is equivalent to killing the program and the block in finally does not run (so the file doesn't get deleted like it should). If I tell it to continue, it doesn't propogate the exception up and instead, it just hits an exception somewhere else.
Is there anyway to get debug mode to continue like a normal program after hitting an exception?
From the Debug menu, choose Exceptions (or use Ctrl + Alt + E). This will bring up a dialog where you can uncheck appropriate checkboxes in the "User-unhandled" column for exceptions which you don't want to stop at while debugging.
I believe that will make exception propagation work normally. And you can still set a breakpoint either in the try or finally block to see what's happening.
Check Debug/Exceptions if there are any exceptions set.
Another option would be to handle the event Application.ThreadException (Windows Forms) or Application.UnhandledException (Silverlight etc.) and tell the application to continue or exit, depending on the severity of your exception.
I've set up an Exception Breakpoint in XCode 4. Will it break for exceptions that originate within the Cocoa Touch framework AND are handled by the framework? I.E. Will the debugger stop for all exceptions, even if they are a natural part of the framework and handled by it internally?
My debugger keeps halting for a seemingly harmless exception from deep down in the framework and I need to know if I can safely ignore it.
If you're like me, there are times you want to ignore particular exceptions (like Apple's intermittently buggy CMMThrowExceptionOnError, which Apple neglects to provide any feedback to my bug reports for months)
So, my not-very-efficient solution is to add the following breakpoint instead of 'Add C++ Exception Breakpoint...'
from gdb command line, enter
break __cxa_throw
Then, in the XCode breakpoints editor, add the following 'Debugger Command' to this breakpoint. By substituting the offending address of $eip, you can exclude individual
exceptions from your breakpoint.
silent
# go up one stack frame silently
up-silently
# in my particular app, address of CMMThrowExceptionOnError is 0x9704d22e
if ( $eip == 0x9704d22e )
# echo gdb ignore exception\n
#print $eip
cont
end
If you can devise a better solution which doesn't incur the overhead of a debugger script, please let me know.
The exception breakpoint is just that: a breakpoint for exceptions. This includes those within the framework. It doesn't matter whose exception it is - if it's raised, it should break.
Just a short note on LLDB used by defat in Xcode 4.3
Commands have a different syntax.
set $eip = xxxx
is now
reg write tip 0x006373ec
a full map of commands is available at http://lldb.llvm.org/lldb-gdb.html
How do I set a breakpoint on an exception?
Ideally I want to be able to see the call stack and local variables from the code that threw the exception.
I haven't used Visual Studio for 2 years, but from memory:
Ctrl + Alt + E
Will bring exception management screen, make sure to check break on all exceptions, a must have imho :)
EDIT : My memory not that bad :) Just check Thrown on Common Language Runtime Exceptions if your are using .NET (CLR = .NET)
EDIT 2 : By the way, since exceptions are generally a bad coding practice and should be avoided as possible, i suggest to let that option enabled all the time. If some exceptions just can't be avoided (because of someone else, of course :D) just uncheck its type or ancestor in the exception type tree.
The exact visual studio command name is Debug.Exceptions
Main Menu > Debug > Exceptions (when solution is open)
Also, make sure you're running in debug mode and that debugging is enabled in the project properties or else all the breakpoints in the world will count for nothing.
(Depending on your environment you can also click on the margin outside the code source to insert a breakpoint via mouse action)