I debugged the following code with F6
in Xcode 6
, and the sequence of execution is very interesting.
Here is the code - 7 lines, a breakpoint is set on line 1:
let request = AWSDynamoDBPutItemInput()
request.tableName = "blah"
let card = AWSDynamoDBAttributeValue()
card.S = "1234"
let email = AWSDynamoDBAttributeValue()
email.S = "notset"
request.item = ["card_number" : card, "email" : email]
When I F6'd through the code, it showed the following sequence (the numbers are line numbers):
1,2,4,2,3,4,6,4,5,6,7,6,7
Why is this? Is this something with Xcode or the language? Those classes are defined in Amazon's AWS SDK, not sure whether that matters, they are accessed through swift-objective-c bridging, could this be related to the bridging.
By the way, the net result of the execution is correct.
New in Xcode 13, if a breakpoint is not resolved to any location by LLDB, Xcode will show you a dashed icon. There is a myriad of reasons why a breakpoint is not resolved but there are some common explanations. If you hover over the unresolved breakpoint icon, we have a tooltip that can help you out.
You might be pushing "Run" instead of "Debug" in which case your program is not running with the help of gdb, in which case you cannot expect breakpoints to work! In Xcode 6.4, there is now only a Run button and whether it runs a debug configuration or not depends on the currently selected scheme settings.
Set a breakpoint to pause on an uncaught Swift Error or Objective-C exception so you can locate the problem. When an unhandled Swift error causes a crash, the debugger shows a fatal error on the line with the try! and not where the error originally occurs.
When you run an application in Xcode, the debugger is automatically started and attached to the process of the application. Click the Run button in the top left or press Command + R. From the moment the application is up and running, we can start inspecting the process and, if necessary, debug it.
I think what you're observing is the effect of the compiler optimizations. It rewrites your code at compile time. For this reason it's normal to disable optimization (-Onone
) on debug builds, but enable it (-Ofast
or -Os
) on release builds.
Finally I got a reply to my bug report from Apple
, and sounds like it was a bug and got fixed in a beta version of XCode
. If you are seeking for a fix, please try the beta:
We believe this issue has been addressed in the latest Xcode 6.3 beta, including iOS 8.3 SDK with Swift 1.2.
Please test with this release. If you still have issues, please include any relevant logs or information that could help us investigate.
This is a pre-release version of the complete Xcode developer toolset for Mac, iPhone, iPad, and Apple Watch. This release requires OS X Yosemite.
Xcode 6.3 - Build 6D520o https://developer.apple.com/xcode/downloads/
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With