“LLDB crash”

It happens every time.. Now I catch this problem in debug. When this happens?: When keyboard is shows and then Loading popup show called which works with adding a view to ViewController's View.. Only happens in ios14 Issue Running 'AppName' popup show up and this message was inside: The app “AppName” on iPhone’u quit unexpectedly. Domain: IDEDebugSessionErrorDomain Code: 4 Failure Reason: Message from debugger: Terminated due to memory issue - System Information macOS Version 10.15.7 (Build 19H2) Xcode 12.0 (17219) And last log was: 2020-10-13 16:29:33.171937+0300 AppName[10638:3084588] [ServicesDaemonManager] interruptionHandler is called. -[FontServicesDaemonManager connection]blockinvoke

Thanks for pointing out my error. Unfortunately I'm still getting the same results with the correct separator: (lldb) po FileManager.default.fileExists(atPath: /private/var/mobile/Library/Mobile Documents/) true (lldb) po FileManager.default.fileExists(atPath: /private/var/mobile/Library/Mobile Documents/com~apple~CloudDocs) false (lldb) po FileManager.default.fileExists(atPath: url.path) false To try to determine that this wasn't just a LLDB issue, I updated my code slightly: func scene(_ scene: UIScene, openURLContexts URLContexts: Set) { guard let url = URLContexts.first?.url else { os_log(URL in %@ is nil, #function) return } let fileExists = FileManager.default.fileExists(atPath: url.path) fileExists is false after AirDropping a file. And of course this is happening within the method where openURLContexts is passed as an argument, and therefore the URL should be valid. So I'm still stuck at the same place.

Have the same exact issue with Xcode 14.2 and have to fall back to command line LLDB. Were you able to fix it?

I also have a lot of logs like this when app becomes paused by lldb: /Users/egormerkushev/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/23S4HX6OW8E8S/MyModule-2XYB5G9W7D2Z.pcm is out-of-date (hash mismatch). Type information from this module may be incomplete or inconsistent with the rest of the program. Rebuilding the project will regenerate the needed module files. When I try print something I get it: (lldb) po self 0x000000015d9de300 (lldb) po self.dismissGestureRecognizer error: type for self cannot be reconstructed: type for typename $s5MyModule31FullscreenContentViewControllerCD was not found (cached) error: Couldn't realize Swift AST type of self. Hint: using `v` to directly inspect variables and fields may still work.

rootView.subviews is empty, while with iOS 18 : (lldb) po rootView.subviews ▿ 3 elements - 0 : > ▿ 1 : > - 2 : >

I gave up on running lldb as a sub-process (even after giving it permissions to attach, it causes lldb, debugserver, and Activity Monitor to hang with 100% CPU). Instead I use something like the above with /usr/bin/sample to get a backtrace when an assertion fails in my debug builds. (spindump must be run as root, so it is useless here)

This is working for me. Consider tiny command-line tool program: import Foundation class Main { func run() { print(Hello Cruel World!) } } func main() { let m = Main() m.run() withExtendedLifetime(m) { dispatchMain() } } main() I set a breakpoint on the first line of run(). I then ran the program and printed self: (lldb) p self (xxst.Main) $R0 = 0x0000600000008030 {} (lldb) p $R0 (xxst.Main) $R1 = 0x0000600000008030 {} I continued and, after a second, paused the program again. This command fails: (lldb) p $R0 error: expression failed to parse: error: :1:1: use of undeclared identifier '$R0' $R0 ^ because the language is wrong. But this command works: (lldb) expression --language swift -- $R0 (xxst.Main) $R2 = 0x0000600000008030 {} macOS: 13.4.1 (22F82) Xcode Version 14.3.1 Ditto. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Not entirely sure what should happen, but I get this: ❯ lldb env/bin/python (lldb) target create env/bin/python Current executable set to '/path/to/env/bin/python' (arm64). (lldb) r Process 33134 launched: '/path/to/env/bin/python' (arm64) Process 33134 stopped * thread #2, stop reason = exec frame #0: 0x0000000100014a40 dyld`_dyld_start dyld`: -> 0x100014a40 <+0>: mov x0, sp 0x100014a44 <+4>: and sp, x0, #0xfffffffffffffff0 0x100014a48 <+8>: mov x29, #0x0 0x100014a4c <+12>: mov x30, #0x0 Target 0: (Python) stopped. (lldb) Separately, I tried signing my python binary like this: ❯ cat entitlements.xml com.apple.security.get-task-allow ❯ codesign -f -s - env/bin/python --entitlements entitlements.xml env/bin/python: replacing existing signature ❯ codesign -d -vv env/bin/python --entitlements - Executable=/opt/homebrew/Cellar/python@3.10/3.10.12_1/Frameworks/Python.framework/Versions/3.10/bin/python3.10 Identifier=python3-555549447295e55955d43a

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. so the -X shell processing in lldb is different to the actual shell. Yes. This is LLDB’s idea of shell processing; it doesn’t invoke an actual shell. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Where did you get your copy of GDB from? The standard Apple tools use LLDB, and have for a number of years. Getting GDB to work on modern Apple OS releases is going to be tricky. I strongly recommend that you use LLDB instead.Share and Enjoy — Quinn “The Eskimo!” Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

Thanks for your response.I totally thought lldb would pass on signals to my process! Thank you for pointing out this isn't the case - asking lldb to do so fixed everything. Feel foolish now.As for your earlier question, I'm using signals to notify me when my aio_read() completes. I know there are other options, but from my understanding, this API has the lowest overhead. Building game engine, and this is part of the platform-side of the asset system.