When I call stop on my AVAudioRecorder instance XCode stops at a breakpoint. However, no exception comes up and I don't have my own breakpoint set there. I do have an "All Exceptions" breakpoint setup.
I hit continue and the app runs fine - no message in the console.
What's going on?
It is the All Exceptions breakpoint. AV Foundation is throwing an exception and also catching it, so no harm, no foul (which is why the app can resume without a problem) - but you are set to break when that happens, so you do. When the app runs for real (independent of Xcode) no one will know; it's just Xcode and your All Exceptions breakpoint that brings it to the surface.
AV Foundation is full of places like this. I regard it as a bug, but not enough to care very much. I just turn off the breakpoint when working with AV Foundation; otherwise we'd always be stopping...
Try 'step in' at method declaration in your code. This should take you to the definition of method being called, and you can 'step over' from there. Hope this may help you.
Related
I'm trying to write a debugger.
My problem is, debuggee windows is left open even after the ExitProcess in it is called. Debugger receives EXIT_PROCESS_DEBUG_EVENT, but debuggee window is still visible and does not react to anything. It does goes away with the closing of debugger though.
What can be the cause of this?
Just as RbMm said, "faster of all you not call ContinueDebugEvent on EXIT_PROCESS_DEBUG_EVENT"
RbMm, copypaste your answer as answer if you care about reputation, I'll accept it.
I've just encountered a really bizarre scenario and can't find any info on this elsewhere. When Xcode breaks at my breakpoints, all keyboard entry for the whole system is unresponsive. I can switch to another app but no key strokes are recorded. Xcode itself is unresponsive to keyboard input.
Anybody else seen this?
I'm running 10.10.1 and Xcode 6.1.
Based on the comments above it would seem that this issue has to do with behind the scenes details of Powerbox. To explain further: my app is sandboxed and calls NSOpenPanel. When breaking (Xcode breakpoint) in the completion block of NSOpenPanel I experience system-wide keyboard input loss.
Keyboard entry behaves normally in breakpoints outside of the call to NSOpenPanel. After working past this area of code I observed that my subsequent operations (queued in the background from the completion bock) often finish before the NSOpenPanel is completely torn down (disappears from the screen). My assumption is that until NSOpenPanel is removed from the screen (and maybe further after), Powerbox won't release control of the keyboard.
Much of this is assumption since I don't have the actual Powerbox code and can't step into it but it seems to fit.
I worked around my debugging issues by utilizing print statements and stepping through code with the variable inspector open. Mouse input continues to function so you can right-click (if you have a two-button mouse) on the variable and print its description at least.
Thanks for the help Ken.
UPDATE
I am now delaying execution of any of my post-NSOpenPanel actions using dispatch_after. On my system a delay of 1 second is doing the trick. I really don't like adding arbitrary delays but this seems to work.
There's some new strange behavior in Xcode 4.4 (Mountain Lion) I'm hoping someone knows how to fix.
Every time I set a breakpoint, when the debugger reaches that breakpoint and pauses, I have to push 'continue' 5-10 times to actually proceed past the breakpoint.
Now, it doesn't appear to actually be refusing to do anything for the first 9 clicks. Rather, (and this is critical) although the bold this part is your code lines don't change at all, the apple internal dispatch threads do change.
For example:
It's almost as if the 'continue' action is continuing deeper through a stack of apple internal calls which exist between when the last piece of my code that called the breakpoint was called and when the breakpoint was called.
Anyway, it makes using breakpoints impossible, as I can't actually keep track of program execution and am clicking 100s of times for every build. New in 4.4!
Anybody experienced this? Any ideas on how to fix?
I recently had my xcode upgraded to version 4, and I have an EXC_BAD_ACCESS exception in my code, but despite setting NSZombieEnabled in the environment it's still showing the break point on the thread1, int retVal = UIApplicationMain(argc, argv, nil, nil); line.
I'm sure I had this configured in XCode 3 to stop on the line of my code that was causing the exception. Now it doesn't do that and displays no error messages in the GDB window either.
Does anyone know what I might be missing?
Thanks
Ray
EXC_BAD_ACCESS is not an exception, at least not as far as breakpoints are concerned - it means the code is trying to call a method on an object that does not exist anymore, because you released it.
The easiest way to find this in XCode4 is to run Instruments (Cmd-I), and in the dialog that pops up asking you which instrument to use, choose "Zombies". Then do whatever to cause the crash, and you will see a dialog pop up with "Zombie Messaged". Click on the little arrow and you will get a history of what created, retained, or released the object. Then you can figure out who released the object early.
My Visiual studio hangs all of a sudden when debugging the windows application. It's takes while to repond and but it's closing my application. I keep getting this issue everytime in every debugging session.
Please help to fix this problem.
Your application also stops responding right? If so, I presume that your application is giving VS problems. Presumably because some operation is tying up the main thread. When that is tied up no other events can be processed (button clicks, screen redrawing, close buttons, etc). That could be caused by an infinitive loop, or perhaps Disk IO or waiting for a network connection or a database query result, or a deadlock.
My suggestion would be to do some type of logging so you can identify where the problem is at. For instance, put a breakpoint at the top and bottom of major functions. After you break at the top one, hit play. If you don't hit the bottom one you know that the problem is somewhere in that area.
Or, do some sort of logging like putting Console.WriteLn("Entering MyFunction()") at various places in the code.
Once you know where the problem is at, you can fix it.