I'm on Xcode 4.5 (although this has happened with previous version) and I find that when I set breakpoints, sometimes they hit repeatedly whereas NSLogging my logic is only traversed once. I've ruled out the usual suspects such as some basic problem in my logic that is inadvertently calling into the breakpoint when the program stops at one. My conclusion is that there is a bug with the debugger that makes the breakpoint hit repeatedly, but this seems to happen even when I step through a few lines of code then continue to run.
Has anyone seen this occur before or even better know a way to alleviate this issue?
Related
Is there is a way for debugging Delphi program in Rad studio with graphic output?
This means even graphic output(the command that has graphic output like print or shows a message and ...) run step by step.
For example inside loop command, we put print or add an item into list view and if we debug this part we can see the result in the form step by step? each turn of the loop show one print or adding to the list separately(by pressing F7 or F8 for debugging)
I hope I have asked my questions correctly.
Thanks
Is it possible to Debug Delphi applications in the way you describe? I'm afraid it is not.
Why not? Both application logic and UI rendering are done within the main thread. And when you set a breakpoint at certain line of code it stop the execution of the entire thread that the code is being executed from.
Since most if not all of your code is ran from main thread setting a breakpoint halts execution of the entire main thread of the application and thus prevents application windows to be redrawn.
In fact since redrawing of windows content is done during idle time of your application it means that running any long loop inside main thread means that the application UI will be updated only when the loop is finished.
You could theoretically force your application to update its UI on each loop cycle by calling Application.ProcessMessages before halting the code on a specific breakpoint.
But using ofApplication.ProcessMessages is not recommended as it could lead to scenarios where messages are not handled in expected order and thus could potentially cause you more problems elsewhere.
Also calling Application.ProcessMesages could seriously affect your application performance so if you decide to use it only use it for Debugging purposes.
I have a following setup:
LuaJIT 64bit in .NET managed, 64bit LuaSocket dll
ZeroBrane 1.80; MobDebug 0.705
Then I have several Lua scripts that are to be launched on specific events and I m trying to debug it.
First script - scripts/OnCreateInstance.lua also starts the MobDebug.
Debugging is working fine in this first script - debugger gets connected on require('mobdebug').start() and also following breakpoints work as expected, but breakpoints in other scripts are never hit.
I've went through the https://studio.zerobrane.com/doc-faq#why-breakpoints-are-not-triggered and haven't found anything suspicious.
debug.getinfo(1,"S").source returns scripts/onstartinstance.lua and scripts/onpushbutton.lua for the second script, which is correct. I am on Windows, so case sensitivity should not apply, and when I've switched the debugger verbose, I've still never seen any info about hitting the breakpoint.
I've also tried listing all the breakpoints in the second script, and all the breakpoints are listed, they just don't hit.
Do someone have any idea, what could be the problem? My only idea is, that it could be because of the second script is run from a different thread that the first script, but that is a thing I cannot avoid and have no idea how to work it around...
Thanks for any help
If the project directory is set correctly and the breakpoints are not triggered from other threads (not individual Lua states), then try adding require('mobdebug').on() calls to those threads/coroutines to enable breakpoints (as described in the first option in the documentation).
I am working with my app in test flight now and I have experienced this maybe only one time myself. How can I get to the bottom of a rare crash without it being hooked up to the computer? The only information is that it occasionally will freeze, but other than that it doesn't seem to be happening with a specific action. How do I debug this?
Here are some approaches:
Write log files to the disk, which you can later sync. or send to a server for investigating which operations succeeded before it crashed
Integrate a custom (such as KSCrash, Crashlytics, etc.) crash reporter tool that allows you to see a backtrace (Note though that enabling Bitcode will make things much harder)
Try to reproduce the problem in the simulator (try different builds, debug build, release build, send memory warnings, etc.)
Try to reproduce with a computer connected. Interactive debugging makes things so much easier.
Good luck!
First of all, I'm sorry to ask a somewhat vague question but I'm only doing it because I'm clueless to what might be causing the problem.
I've been building an app with Sprite Kit and it has worked great. I've made some additions to code at suddently I see a dramatic decrease in performance. I have rolled back all my code changes but the performance didn't go up. I'm left clueless to what's wrong.
After hidious debugging I've noticed that the performance problem only affects run and test builds. If I do a profiling build, the app behaves as normally = with high performance. So this would suggest that my problem is somewhere in the build configuration but I'm completely new to ios build environment configurations.
Can anybody suggest what might be the cause of this? Where should I start looking? I have my background in Java 5 and the compiler and other settings are quite strange to me.
The default setup is to have a Debug config and a Release config, where Debug is configured with no optimizations, and Release does include optimizations. Optimizing often makes it hard to use the debugger, which is why unoptimized code is preferred there.
By default, Run, Test, and Analyze use the Debug config, Profile and Archive use the Release config. Your change in behavior could come from lots of differences: you may have had it configured before to build for Run in Release mode. You may have had a subproject built in Release mode that is now in Debug. You may have made a coding change that is very slow unless the optimizer is used. (Since you say you rolled back the code, this last one is unlikely, but check your version control and see if you changed any project settings.)
If you're seeing weird "it wasn't like that before" behavior when you think you've put everything back, make sure you're rebuilding everything. Delete your Derived Data directory. You can determine where it is in Preferences, Locations. "Delete your Derived Data directory" is the Xcode-equivalent of "try rebooting." It's the most common way to fix strange "Xcode isn't working right" problems. In fact, I put my Derived Data in /tmp/build so that it gets deleted every time I reboot (and so the path is easier for me to remember).
occassionally, and without a specific pattern, I run into a situation where the rascal interpreter does not proceed with a debugging session. In the progress window, I get the message:
Reconnecting importers of affected modules: running command.
However, the progress bar remains static. What is causing this to happen? I cannot seem to rid this even if I restart eclipse. It usually starts happening after I start a debug session in a buggy code, then insert a few breakpoints.
Although this is not really a coding question; it may be this is the same UX feedback problem that I've experienced. Since Eclipse Luna and the latest Keppler updates, only when you go into the Debug perspective you see that Rascal is pausing on a breakpoint and the cursor jumps to the right editor. From that view you can then press the Run button to continue finishing the run.