“LLDB crash”

After spending several hours profiling lldb, I have identified the reason behind the high CPU usage and slow app launch and breakpoints. It turns out that a custom xcconfig file was disabling dSYM for the Debug build. However, once I restored the dSYM in the Derived Data Xcode, both lldb and our app started up quickly again.

Incidentally — I am playing with the login item to test the hack, and I have found that there's some pretty convenient trickery, probably at lldb level:if my login item is launched properly (i.e., through SMLoginItemSetEnabled), it works as expected;if my login item is launched manually (e.g., by running its executable from Terminal), it does not work, the service is invalidated — fully as expected, of course;if my login item is run by Xcode (or manually in lldb) though, the XPC communication does work!That's a really nice surprise; I have expected to debug, I would have to launch the login item through SMLoginItemSetEnabled, and to connect lldb to its pid. Kudos to whomever designed/implemented this little trick!

Well, if I set process handle -s false SIGCONT At application load, then the test continues without entering the debugger. That doesn't help by itself because it still requires manual intervention at multiple points during the test suite. I haven't found any good documentation on custom LLDB settings, especially settings that take effect after the process is running. I've verified that .lldbinit is read on start of the testing and again when the process enters the SIGCONT break point. The problem is that the process handle . . . command is target-specific, and can't be run without a target. Even when breaking for SIGCONT I get an error about an invalid target for that command. Is there any documentation on how to override LLDB behavior from a configuration file, including commands which only take effect in a specific process? For example when LLDB attaches to a target do X. A way to change global LLDB behavior would also be good if one exists.

Duh, I assumed that PKPhysicsWorld was a typo, but I just tried adding the category and found out this is the class name. It turns out that Sprite Kit is playing shenanigans with classes:(lldb) po [self.physicsWorld className] PKPhysicsWorld (lldb) po self.physicsWorld.superclass NSObject (lldb) p [self.physicsWorld isKindOfClass: [SKPhysicsWorld class]] (char) $1 = 'x01'So it's not a SKPhysicsWorld class cluster, and PKPhysicsWorld is not a subclass of SKPhysicsWorld, but it does pose as a SKPhysicsWorld!If you must add the method, you might be able to do so by manipulating the Obj-C runtime metadata directly, but it doesn't seem like a good way, going forward.

@frameworksengineer I'm also running into this in iOS 15 in a UIKit app. When it happens the textField isn't visible anymore, although I still see it in the View Debugger. I think it happens when I enter some text and then tap outside the textField. I see the Assert warnings a number of times and also this one: WARNING: Calling updateFocusIfNeeded while a focus update is in progress. This call will be ignored. I did what you ask and the UITextField.interactions[UITextInteraction].textInput property is simply the UITextField. (lldb) po (UITextField*)0x7f9fd7c2d200 ; text = '1.99'; borderStyle = None; background = <_UITextFieldNoBackgroundProvider: 0x7f9fe29e0120: textfield=>; layer = > (lldb) po ((UITextField*)0x7f9fd7c2d200).interactions <__NSArrayI 0x7f9fccbb1600>( , , <_UITextMenuLinkInteraction: 0x7f9fc6880dd0>, , <_UIClickPresentationInteraction: 0x7f9fc68819e0>, , <_UIKeyboardBasedTextSelectionInteraction: 0x7f9fc4b71ef0>, , , , , , , ) (lldb)

Latest release version appears to be: lldb-340.4.119OSX 10.11.2, Xcode 7.2 release

I already had a radar: FB9958917 Thanks for filing that. Some notes: We can definitely reproduce it in-house. It seems to be related to Xcode’s console pane, not LLDB itself. If running lldb from the command-line is an option for you, that’s a simple workaround. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

My understanding is that you’re doing this: Run app with identifier A. Test it from LLDB. It works. Change the app to use identifier B. Test it from LLDB. It fails. If you delete the app from the device between steps 3 and 4, does that help? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Anything I should look for or do, other than telling lldb to attach to the correct pid, and wait for a crash? That’s the obvious place to start. If you want to write more code you could: Investigate core dumps. Install a SIGABRT signal handler than stops the process to allow you to attach. Disable SIP and start messing around with DTrace. We might get to that point, but they all see like overkill right now. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com