I am fairly new to Xcode and I have a question regarding how to trace back a bad access exception.
When I run my program in Xcode 6.4, it crashes and says there is a bad access somewhere. I can look into it and see all the assembly codes. However, when I try to use exception breakpoint to trace where the bad access actually comes from in the source code, nothing happens.
I have no idea what is going on and it would be appreciated if someone can help.
"Bad access" has nothing to do with exceptions. It's a signal, not an exception. Your program stops exactly at the point of the bad memory access. Follow the stack trace up to identify the code calling it. More importantly, use the static analyzer to show you problems, and turn on warnings to show you even more problems.
(The reason why you should set an exception breakpoint is that exceptions - not signals - end up in the debugger when it is found that nobody is catching the exception, at which point lots of evidence is destroyed. Exception breakpoint stops right when the exception is thrown, so you can follow the stack trace as well).
Related
I'm writing some 32-bit Windows assembly that will detect edits to my program.
I'm not really sure why, but using VEH to debug a checked address causes it to crash (there is nothing against debugging yet, just memory edits), throwing an exception_single_step in the middle of my checking code. I'm not using breakpoints, I'm tracing accesses.
How can I "catch" it without attaching my own debugger? I may have implemented it wrongly but my makeshift exception handler does nothing when it is raised (mov fs:[0], 0, even, does not cause it to crash as one would expect).
Am attempting to learn Swift and am building an audio application inside of OSX.
I am attempting to debug the code, and I am experiencing the following error:
ESX_BAD_INSTRUCTION(code=EXC_I386_INVOP,subcode=0x0) at runtime during debugging.
No further information is available from the debugger.
Now, of course I would normally be hard at work by this point googling for a solution, but there is more information...
The function in which this error appears is fairly large, and the debugger line is about 3 lines of code from the top of the function.
Problem is, that the crash happens way down inside the function - in the main loop, and after it has run over 80 times. The debugger appears to be moving its pointer back earlier in the code which is pretty confusing. I can confirm that the execution thread is way further on than the position in the code where the crash is being reported.
Due to the fact that the stack location is incorrect, all the debug variables are missing in the debugger.
Can the debugger be forced to report the correct stack location?
Currently, Apportable doesn't show any stack trace on crash by C/C++ exception.
How can I make it to print stack-trace when it is crashed?
You can use apportable debug to attach a gdb debugger to the app. Then use the command continue to get to the crash; backtrace to see the trace; up, down, and frame {number} to navigate through the trace; and print {expression} to examine state.
More information in the docs page.
For C++ exceptions in particular, you will get a confusing stack trace. We'll investigate adding better debugger support for these. In the meantime you could set a breakpoint on the throw(break __cxa_throw).
I have been running an application developed under Windows 7 in Delphi XE on Windows 7 machine for about 3 weeks non-stop, but it stopped working after that and popped up a message box with "Control doesn't have parent window." After that nothing seem to work right in the software, unless it is shutdown and restarted.
I have an idea of what that error means, but I am trying to figure out. Why?
Any hints or suggestions will be greatly appreciated. Thank you.
Sign of a resource leak, window handles most likely. Diagnose with TaskMgr.exe, Processes tab. View + Select Columns and tick Handles, USER Objects and GDI Objects. Keep on eye on the values for your program while you are using it. A steady increase spells trouble, Windows stops giving more after 10,000.
If that doesn't help then improve your exception handling so you can get a better diagnostic, a stack trace is important to diagnose trouble like this.
You should install a copy of MadExcept, JclExcept, or other exception handling library that supports displaying/logging the call stack when an uncaught exception is raised (if you cannt reproduce the exception while running inside the IDE debugger, that is). Then you can figure out what your app was trying to do at the time of the exception, and hopefully narrow it down to the spot in your code that is accessing the specific UI control that is missing its Parent window.
I've integrated Flurry (http://www.flurry.com/) into my phone 7 app. The only code needed is this line in application launching
FlurryWP7SDK.Api.StartSession(ApiKeyValue);
However, as soon as that line is hit the application crashes with a KeyNotFoundException. The stack trace is included below. It appears to be querying isolated storage settings and failing when the key doesn't exist.
Does anyone have any experience with this error or even successfully integrating flurry into a Phone 7 app?
at System.ThrowHelper.ThrowKeyNotFoundException()
at System.Collections.Generic.Dictionary`2.get_Item(String key)
at System.IO.IsolatedStorage.IsolatedStorageSettings.get_Item(String key)
at A.ca98fb38190f0d5cad84c67a779d17229.c204dba68825403c905efd7bfd067b17b(String ce0360de492f1f363775feaf6d6a8ced5, Object c8d4be677f7ee63f6756e13f285072523)
at A.c3f1105d518a239d73e2236200494de25.set_cfca54db015a16ab23de44b4d5c65e9a3(String c8d4be677f7ee63f6756e13f285072523)
at FlurryWP7SDK.Api.StartSession(String apiKey)
at AppName.App.Application_Launching(Object sender, LaunchingEventArgs e)
at Microsoft.Phone.Shell.PhoneApplicationService.FireLaunching()
at Microsoft.Phone.Execution.NativeEmInterop.FireOnLaunching()
Edit
After discussions with Flurry support it appears that the KeyNotFoundException is caught by Flurry code. However if your debugger settings are to break when the exception is thrown you will break into the debugger regardless. Continuing execution will then work because the exception is caught and handled by Flurry.
I can't verify that this is the solution because I no longer have access to the dev environment that was indicating the error, but it appears to be a likely solution.
I work for Flurry. We have many successful deployments on the Windows 7 platform. You and Buju may be experiencing an emerging issue that has not come to our attention previously. Please email winmosupport#flurry.com as the diagnosis may involve discussing account specific details. Once we determine the underlying cause we can post back to this thread so the community has the benefit of our investigation. Thanks for working with Flurry.
Edit
I just wanted to follow up on Mac's comment as the KeyNotFoundException may manifest in two ways during debugging. As Mac noted we do caputure the KeyNotFoundException, however, the debugger sees the exception first before we can handle it within our library. The debugger's behavior is dictated by the setting in Debug > Exceptions.
If the checkboxes under Thrown are selected the program will be stopped and the stack trace above will be output. If the checkboxes under Thrown are not selected the output will generate an error like the following:
A first chance exception of type 'System.Collections.Generic.KeyNotFoundException' occurred in mscorlib.dll (this is the message Buju received)
The program will continue following this message as it just serves as a notice that an exception occurred somewhere within the program. More information on first chance exceptions can be found in the following articles:
What is a first chance exception - http://blogs.msdn.com/b/davidklinems/archive/2005/07/12/438061.aspx
How to handle (disable) first chance reporting - http://www.helixoft.com/blog/archives/24