Shortly after updating to Xcode 13.2.1 I started seeing some weird behaviour of breakpoints. When I run an app (in a simulator) some of my breakpoints change their look and turn to dotted blue outlined. Xcode does not stop execution at these breakpoints although code has been compiled, loaded and executed. I checked it in Console by adding some prints.
When I hover over breakpoint Xcode shows a message:
Xcode won't pause at this breakpoint because it has not been resolved
Resolving it requires that:
The line at the breakpoint is compiled.
The compiler generates debug information that is not stripped out (check the Build Settings).
The library for the breakpoint is loaded.
All trivial solutions like reloading, reapplying breakpoints have not helped.
Did anybody else see something like this? Is there a way to solve it?
Screenshot for reference:
Ok, so in my particular case rebooting laptop has helped. All breakpoints are now good. But it would still be nice to know the cause of the problem.
Make sure that the file in which you are adding breakpoint is having correct target set in target membership.
Click on .m file in which you want to add breakpoint.
Select the file inspector.
Check if you have selected correct target for that file or not (check below image).
What worked for me, was to select the files, delete them with - Delete>Move To Trash - and then drag the files back from the trash to the project.
In my case the issue was happening, because class was not added to the target, which I was trying to build.
For my case somehow the code path was never invoked and very likely considered as dead code. The same thing applies when not adding the file to the target that you want to debug.
This can be the case or somehow debugger might not be able to resolve your breakpoint. The first thing in this case should be cleaning derived data and any caches.
But instead of recloning your repo you can just delete breakpoint config from the location described in this answer
In Xcode 14 the problem is much more prevalent and "consistent". I figured out one pattern where it always fails and how to mitigate it.
If you have a final class then breakpoints set on or inside a private method will have that issue. If you remove private from the method or final from the class the breakpoints will get resolved properly.
If tried everything and nothing worked I suggest the following:
Reclone your repo
This is what worked for me.
I just passed through this problem and the solution for me was recreating the files.
Note: The ones I was trying to originally breakpoint on were copied from another project. When I created the new files, even though their Identity and Type looked just the same (target membership, encoding, paths), for some reason breakpoints started to work again.
Note 2: When copying and pasting code to your new files (if done manually), migrated breakpoints - created in the older file - will continue to fail. Only the ones created in this new file will work properly.
Hope it helps.
My case
Working on framework development. Framework is injected into the sample app for development/run purpose. Breakpoints inside the framework won't work.
Fix
Just removing xcframework in sample app and replacing with framework.
Reason
xcframework are precompiled outside of the app, so lib isn't compiled when project is built and that's why breakpoints doesn't work.
For me reboot the Xcode, and it works~
Related
Just running my iOS project in the iOS Simulator and then get this error:
"dyld_sim: cannot be loaded in a restricted process"
Kevin Packard's comment gave me an insight on how to work around this issue. So basically there are several options:
As Kevin said, you can simply switch to Release configuration which will turn off Thread Sanitizer.
And yeah, the second option is to turn off Thread Sanitizer directly.
For me, the problem came because I changed folder names and had to delete and re-add files in the process. In doing so, I deleted AppDelegate.swift and SceneDelegate.swift and forgot to add them back. After copying those files from another project and adding them into the one I was working on, everything was fixed.
I have a large iOS project, and my problem is that, when running XCTests:
Breakpoints within the app, or within the tests themselves, are not hit
NSLogs/prints from within the app are not visible within the test log, but logs from within the tests are visible
I have another iOS project within the same workspace, and breakpoints and logging work fine.
The iOS project in question was originally created on an old version of Xcode (circa 2012, unsure which version exactly); and I have seen this comment elsewhere from somebody having seen this issue with an old .xcodeproj.
The project itself is hybrid Obj-C/Swift, uses several Cocoapods, a watchkit extension, and tests divided into three targets.
Given my project's complicated configuration, I would prefer to avoid beginning again with a fresh .xcodeproj and try to mirror exactly the configuration of my faulty one.
What could the reason for this fault be and what might I change within my existing .xcodeproj's configuration to fix it?
Select your scheme, go to Edit scheme... and tick the Debug executable option under the Test > Info pane.
The debugger will attach to both your tests and your target application, and breakpoints will be hit on both parts of your project.
Note that when a breakpoint is hit in your target application, your test is still running and may time out, killing both applications.
The culprit was DEPLOYMENT_POSTPROCESSING = YES in the project file.
This has to do with how your test scheme is set up. I was having the same issue and I fixed mine by turning Debbuging "ON" for the test executable.
I made a new scheme for my UI tests, so I assumed the debugger wasn't attaching to the new UI tests scheme when no breakpoints were hit. However, this post
had the correct answer for me.
In my case breakpoint was not hit in just one callback, so I changed "Swift Compiler" "Optimization Level" to "No optimization" in project target build settings for debug, and it started working in Xcode 9.3 as well as AppCode.
For breakpoint not working case check which Optimization Level you have, if you have the new -Os breakpoints start acting weird, change to -None or No Optimization in debug mode whatever option you have
Problem with logs not appearing in a debug area, in my case, was due to the OS_ACTIVITY_MODE argument which was set to "disable" in Scheme -> Test -> Arguments
I tried everything in the replies as of this date, but in the end the only thing that worked in my case was to remove the target and recreate it again.
I have tried to debug something in my application.I run the app by setting the breakpoint, but the debugger showed me the variables without any content.
Here is an image of what I am talking about, I don't understand why the blue arrow does not appear in the left for each of the variables:
I have also opened another project and when i debugged that one, it worked. Is it related to the settings in xcode?
This is a problem related to use of Objective-C code in swift projects
Check your Bridging-Header.hand remove all unnecessary headers files from there, check if you are using cocoa-pods you need import all your pods with the import sentence, never include the header of that pod in your Bridging-Header.h
I hope this helps you, I just resolve this problem with this method
Make sure you are running a debug build, not a release build. Release builds use code optimizations that get rid of temporary variables, map variables to registers, interleave the code from multiple lines together so you can't cleanly step through line by line, etc.
I've searched around and can't find anything on this.
Using Swift 2 and Xcode Version 7.0.1 (7A1001). Every time I execute something in the debugger console, Xcode crashes.
The project is not very big, and has less than 10 third party frameworks.
I can't think of much more information that's relevant, but I'm sure there's more, so please do ask me if there's anything I should add to my question that would help.
I've of course cleaned build and derived data.
It's driving me insane. Thanks!
UPDATE 16/11/12
Submitted rdar://23559366.
How are you maintaining your third party frameworks? Via Carthage?
If so then this is probably your issue: https://github.com/Carthage/Carthage/issues/924
This is an issue if the location of the /Carthage/Build/iOS folder is in a different location to where it was produced (i.e if it was compiled on a different machine and the absolute file path has changed).
A temporary fix would be to run carthage build --no-use-binaries on your machine to rebuild the symbols using the current absolute file path working around the bug.
But if you wasn't using carthage then its probably not your issue so sorry
I had similar problem with Xcode whenever I hit breakpoint.
In case you see this screen right before your Xcode crashes - you are lucky and my fix might save you. All you need to do is open this window and in the Project Navigator, select any file that you want, so that instead of that white blank view you would get your code. After this you are most likely will be able to successfully stop your app at your breakpoint and perform the debug.
I am not sure why this happens, but I suspect that the reason is Debug View Hierarchy mode, which you might have triggered prior to setting you breakpoint and trying to stop at it. At least this is when it happens to me.
I have similar problem earlier.
If you try to print non-optional variable and unfortunately it holds nil value then it breaks/crash. so that make sure declare all possible variables as "Optional type".
I downloaded a project made with Delphi 2009,which is also what I use,however there is one breakpoint that I just can't remove.If I try to remove it,its being executed again after the program is executed.
I met such things in other debuggers known as Hardware breakpoints,but this is not important.How do I remove the breakpoint?
EDIT: Article about those breakpoints,but It doesn't explain how to remove them.
If, for whatever reason, you can't turn these off in the IDE, as Rob says, this is persisted in the .dsk file.
You don't have to delete the file (and all of your other settings), though. you can just open it up in a text editor and find and edit the following section:
[Breakpoints]
View->Debug Windows->Breakpoints.
I'm very dissapointed at those articles.They explain how to add something,but not how to remove it.
Breakpoints are stored in the dsk file for your project. Close your project, delete that file, and re-open the project. All breakpoints should be gone. (Other window-layout customizations will be gone, too. You'll have to restore those preferences manually.)