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?
Related
I have an OpenGL application that uses GLFW under OSX 10.12.3.
50% of the time when I run it it works fine. When glfwPollEvents() is called from my main loop, the mouse callback is called correctly for mouse events.
However, the other 50% of the time it doesn't receive ordinary mouse events even though a window is correctly created in the foreground. The main loop is running but the mouse event callback isn't called. If I double click (two clicks within around 0.1s) then the event callback receives 4 events as expected. But it receives nothing for single mouse clicks.
Within the main loop glfwGetWindowAttrib(window, GLFW_FOCUSED) returns 1 when the code is working and 0 when it isn't. Adding glfwFocusWindow(window) after window creation doesn't seem to change anything.
If I switch focus to a different application and switch back then my application starts receiving events correctly.
I have used GLFW 3.1.2 built using homebrew, and GLFW 3.2.1 built directly from a github clone. I get the same behaviour either way.
For a while I thought glfwWindowHint(GLFW_FOCUSED, 1) fixed my problems but after the 10th launch or so the problem returned.
I'd like to avoid posting my code (whose glfw calls come mostly from tutorials anyway) and I'm hoping someone will recognise the symptoms I describe as some obvious mistake I've made. The double click behaviour seems like a big clue.
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.
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.
When Im debugging my app in VS2012 and it crashes, the input (mouse and keyboard) starts to lag extremely, the fps drops to about 0.3 or less and I can't even move my mouse without waiting 3 seconds... The only solution is to do Shift-F5 which will end the debugging, and everythng is fine then again.
Whats more interesting, the only lagging thing is the input, the whole background works perfectly fine, text caret is blinking at normal rate and tooltips are nicely animated when mouse gets over a button.
Im compiling the project with allegro 4.2 (I have to use it, it would take too long to explain why).
I have no extensions, a pretty fast pc which should be able to handle debugging...
Im interested in any solution, it may be dirty/hackish... I can of course provide more information if needed.
Thanks for any help.
EDIT: Reading through forums I found some information about the "Auto" window or something like that (don't remember exactly and can't find it anymore), which is doing some "background tasks" and that causes lags... Do you think running it on separate core would fix that?
A tale of multi-second stalls when hitting a breakpoint, related to the raw input API: http://the-witness.net/news/2012/12/finding-and-fixing-a-five-second-stall/ (archived)
It's a very long time since I last saw this sort of thing myself, but I seem to remember that the culprit in my case was DirectInput. (This makes some sense, given the tale above, as DirectInput has long been a wrapper over the raw input API.) And I think the solution was to use the emulated keyboard and mouse devices rather than the default ones, which you do this by passing in one of the emulated device GUIDs to IDirectInput8_CreateDevice. Discussed briefly here: http://msdn.microsoft.com/en-us/library/windows/desktop/ee416845%28v=vs.85%29.aspx
(I don't remember whether cooperative and exclusivity levels made a difference - it might be worth trying changing these too.)
I recently experienced the following similar issues while debugging a game:
Hit a breakpoint, halting the program for debugging.
Pressing any key now takes around 1 second to "process". It will be buffered and sent slowly one after another to whatever window is now active.
In my case, the application installed a low level keyboard hook with SetWindowsHookEx(WH_KEYBOARD_LL, ...). After removing this (for !NDEBUG builds only as you wish), the input lag was gone.
I suppose the hook cannot respond at all while your application is halted, and eventually the system skips it after a timeout, which length can be configured in milliseconds under HKEY_CURRENT_USER\Control Panel\Desktop\LowLevelHooksTimeout:DWORD as mentioned here. In fact, the link in the accepted answer mentions this issue, but I thought I explain the core of it right here, also because the link went dead before I fixed it.
Try to find such a hook in your application or dependencies, and check if removing it helps. Since you mentioned this happens to your mouse too, check for a (low level) mouse hook (WH_MOUSE_LL) aswell. The available hooks are listed on MSDN.
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.