Friends,
I am building and debugging my xproj. Now the control is not stopping at the breakpoint i kept in the program but it is stopping at the return statement of operator++() in the stl_iterator.h file. After I press Continue the code is giving expected results but the thing is I cannot see the step by step debugging. Can any one give me clue why it is happening so, always i see the control at same position. I cleaned all targets and tried but no luck.
Active SDK = iphonesimulator4.0, Active Configuration = Build. (I used C++ in the code).
With iphoneSImulator3.1.2, i can able to debug step-by-step for the same code.
Thanks in Advance,
Anil
Sometimes the compiler will optimize your code and make breakpoints move around. Be sure to turn off all optimizations when building for debugging purposes; this should already be set in the “Debug” build setting.
Related
I am using Unity as a library for SwiftUI quite a while now. However when updating to the newest iOS version (16.1) it stopped working. Compiling runs without a problem but during runtime I get an error when Unity is starting:
in:
I even started a completely new project with Unity included to SwiftUI and get the same error. As this is some kind of assembler code and I certainly do not know how to read it I don't really know where I have to start searching.
In the console I get: "warning: UnityFramework was compiled with optimization - stepping may behave oddly; variables may not be available." I tried several ways to turn off optimization as described in related questions which did not work. When unchecking "Debug" in the scheme options the project starts normally
A similar thing happened to me. I'm not entirely sure if it's the same problem but in the console, I got a message saying UnityFramework is running optimized and may behave oddly. Unfortunately, I've tried a couple of ways to disable optimization but I've yet to find a solution.
For now, I'm able to bypass this error by disabling the debugger entirely. In order to do this, you have to go to Product -> Scheme -> Edit Scheme and uncheck debug executable.
I'm not sure if this will work for you but I figured it'd be worth a shot!
I'm building a flutter app in VsCode
When am ready to lunch my app
I use Run -> start debugging in vsCose
But alternatively I can use Run -> Run without debugging
So what the difference between the two?
In Debug mode, you can pause your application at so called break points. This can help you to find bugs in your code. You can also figure out, which values your variables consist at a speficic part in your application.
You can set a break point by double clicking on the left of a line number where you want to pause your code from running (see here: debug break point example)
Debug mode is for development. As such, the binaries are larger and slower, because they have e.g. the names of all your functions stored alongside line number information for debug tracing to work. Hot reloading is also an important feature of development or debug mode.
When you run in production mode, all the debug information is stripped away, the app loads much faster, and all debug information is elided from the binary that is produced. It is for end-use.
start debugging mean's in debug mode, it is best when you want to debug your app. you can set multiple break points and check what is value of that variable at particular point of time.
Run without debugging mean simple run where your break points doesn’t matter.
Moreinfo: https://flutter.dev/docs/development/tools/vs-code
I have an issue where when I run my application in debug mode, the application shows obvious runtime lags. As specified in numerous articles, the application bundle will run up to 10X faster than when running from xcode (including with instruments).
However, when I open the app (going through the project explorer/products/app_name.app) and show in finder then run the app, several features that work perfectly in debug mode (in my case, certain keyboard press functions).
The app runs much faster as expected than the debug mode runtime, but lacks some of the behaviors which work in debug mode. Furthermore, some other actions close the application altogether.
I don't know where to start figuring this out but have some intuition and would like confirmation what it might be:
1-Instruments: is there a difference of memory usage between debug and application bundle for which debug keeps a cap on memory usage, CPU usage etc?
2- COnsidering cache misses, is it possible that my nSResponder when I activate a key does not catch some later down the track switch cases, which will create a cache miss? (I doubt this since my controls file runs as an extension to one of my main loops). Note: If this works fine in debug mode, why would it not work in the application itself?
Any pointer to why this behavior greatly appreciated, so that I don't make large changes that won't affect the outcome (It's a large project).
So are you saying that when you compile for debugging (-ONone), then things work. But when you compile for release then some things don't work?
Try unchecking 'Enable backtrace recording' in the Options tab of the Run scheme action.
Bounty Update
I am leaving the question essentially the same, but I just want to point out at the beginning here that I'm most interested in help trying to get the socket between flash (Adobe Animate) and the native debugger working again, as I believe that is the issue I'm having. Or is it a socket between flash and Windows?
Original Question
I've apparently turned something off? Even when I write really bad code (like trying to call a function that isn't there or divide an integer into a fraction), the flash player boots, shows a background color and stops there. No messages in the output window or compiler errors window. If I fix my code, it all runs fine, but for about 30 minutes (ever since I started trying to work with bitmaps for a sprite sheet) I get no runtime errors no matter what kind of mistake I type in my code. Anyone know how to turn it back on?
I've checked my actionscript settings and I have both warning mode and strict mode checked on.
Could it be a socket issue? I admit I have little to no experience working with sockets and only a surface understanding of what that even means. I've added the socket tag. If someone can see that this is clearly nothing to do with sockets, by all means, I'll remove the tag.
UPDATE: 6/22/16
I just reinstalled Adobe Animate CC 2015.2 and no change. I'll try compiling it in flash builder when I get a chance to help pigeon hole the problem. (Edit 6/24: flash builder worked! But my trial version expired the next day so is no longer a viable option).
And I just tried something in the command prompt in Windows 10 as an administrator:
netsh winsock reset catalog
netsh int ip reset reset.log hit
which I found another user on flashdevelop.org used to fix a similar issue, but no change.
And I just tried debugging in Flash Builder. It worked fine (debugger caught bugs) but my trial version expired the next day.
update 6/24
I've tried launching debugger for AIR from within the Adobe Animate CC IDE and it works fine if there are no bugs; it fails to do anything visible (no Iphone emulator, no swf window) if I put a typo or error in the code.
I also just deleted winsock and winsock2, rebooted Windows, then reinstalled winsock and winsock2. No change.
update 6/25
Just tried a system restore in Windows to set all my files and settings and drivers etc. to the way it was a week and a half ago... Also completely uninstalled all Adobe products and reinstalled. No change. I can only imagine that wiping my hard drive and reinstalling Windows would do the trick, but come on, it hasn't come to that has it?
As VC.One suggested, I checked the compile error window (cannot believe I didn't check before! Maybe when I checked before there were no compile errors... Only runtime errors?) and the errors are showing up there. Does this mean that it's catching compile errors but just not runtime errors?
When you force/test a runtime error... make sure you check
Compiler Errors (ALT+F2) and also Output (F2). By Output I mean the window that shows traces (and runtime issues). One of those two should have some feedback for you.
A possible solution is to save a new Workspace. So with those windows for Compiler Errors and Output both open (or tabbed, I tab them next to my Timeline) go to Window (in top options like File/Edit/Debug etc) and choose Workspace, then into that you choose New Workspace. Give it a name in the pop-up and okay everything.
Flash should always load that current workspace (next time, go to Workspace option again, check that your specified workspace [by name] has a tick next to it...).
Possible pitfalls:
1 - Use the debug player
2 - Make sure there isn't somewhere a try/catch enclosing the portion of code that triggers the event that may lead to an error
3 - Socket issue: may be exported in debug mode but swf cannot connect to debugger (it waits in a blank state for 60 seconds I guess)
4 - Does it compile ok? If there are compilation errors you may get an SWF anyway but then it will not start
...
From times to times, while debugging an Application, I see this error on Xcode:
Program received signal: “EXC_BAD_ACCESS”.
and the debugger does not stop on the problematic line. In fact the debugger just shows me a page with a bunch assembly language code and that's it.
I have to have paranormal powers to figure out where the exact problem is.
Is there a way to force Xcode to give me more "nutritive" error messages – that can detail the problem – and stop on the offending line when such errors occur?
thanks for any help.
When the crash happens, open the Debugger in Xcode (Run -> Debugger). There should be 3 to 4 panes like this:
http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/XcodeDebugging/art/debugger_disassembly.jpg
On the top-left pane (the "stack trace"), select the topmost row which is not gray.
(Note: Sometimes the stack trace can only find internal functions because of bad memory management triggered in the run loop. Try to Build -> Build and Analyze to eliminate all potential memory management bugs first.)
You can enable NSZombies see here and I've found a good way to see where the actual problem is, is to run and debug the program with the debugger open.
This way when the program stops executing it more often then shows the line that was executing when the program crashed.
I wrote up a blog that tells you how to use some compiler switches that help a lot in finding crashes that are the result of releasing objects before you are done with them.
http://loufranco.com/blog/files/debugging-memory-iphone.html
Build and Analyze is ok, but not as good as scan-build (which it is based on). Instructions for installing that are here:
http://loufranco.com/blog/files/scan-build-better-than-build-analyze.html