“LLDB crash”

(lldb) image lookup -a 0xffffff801a5ac283 Address: kernel[0xffffff80003ac283] (kernel.TEXT.text + 344707) Summary: kernelpanic + 99 at debug.c (lldb) image lookup -a 0xffffff801a6d91ea Address: kernel[0xffffff80004d91ea] (kernel.TEXT.text + 1577450) Summary: kernelpanic64 + 218 at trapnative.c:152 (lldb) image lookup -a 0xffffff801a55a51f Address: kernel[0xffffff800035a51f] (kernel.TEXT.text + 9503) Summary: kernelhndl_double_fault + 15 (lldb) image lookup -a 0xffffff801a6cd95f Address: kernel[0xffffff80004cd95f] (kernel.TEXT.text + 1530207) Summary: kernelusimplelock + 47 at machineroutines.c (lldb) image lookup -a 0xffffff801a5c95ad Address: kernel[0xffffff80003c95ad] (kernel.TEXT.text + 464301) Summary: kernelthread_dispatch + 445 at sched_prim.c:2768 (lldb) image lookup -a 0xffffff801a5c906e Address: kernel[0xffffff80003c906e] (kernel.TEXT.text + 462958) Summary: kernelthreadinvoke + 1710 at schedprim.c:2559 (lldb) image lookup -a 0xffffff801a

I have the same issue with lldb in my project!Both Beta 2 and 3 give meerror: Couldn't lookup symbols: __swift_FORCE_LOAD_$_swiftCoreMIDIwhen trying to execute any lldb command.This is the case only with a real device (I've tested on 12.3.1). On simulator lldb works properly.

@rickbdotcomSame story here. Excluding 3rd party framework from Carthage (which was distributed as pre-compiled binary) and compiling/linking it directly within the project – does fix Xcode crash and restores lldb breakpoints functionality.Thanks!UPDATE: It is possible to force Carthage to build frameworks from sources by passing additional argument carthage update --no-use-binaries

Another strange thing is that when dragging the crash report to the Xcode dock icon, the Xcode console logs this error: User Command: command script import -s lldb.macosx.crashlog User Command: crashlog --interactive --skip-status --no-parallel-image-loading ~/crash.ips Resolved symbols for 0A35BC69-660D-3BC0-8AB4-3FA8D922EECB /usr/lib/libobjc-trampolines.dylib... Resolved symbols for 79EFE8B6-A212-3E98-B801-C9F2BF18EA68 /usr/lib/dyld... Traceback (most recent call last): File /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/Python/lldb/macosx/crashlog.py, line 1444, in __call__ SymbolicateCrashLogs(debugger, shlex.split(command), result, True) File /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/Python/lldb/macosx/crashlog.py, line 1855, in SymbolicateCrashLogs load_crashlog_in_scripted_process( File /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/Python/lldb/macosx/crashlog.py, line 1557, in l

Based on a post i found I tried deleting ~/Library/Preferences/com.apple.dt.Xcode.plist ~/Library/Caches/com.apple.dt.Xcode Which helped in the way that I can now Run the extension like a normal app, just choosing Finder as the host app. It hits the breakpoint but the same issue as above -> crash upon stepping over or upon usage of lldb.

This is caused by Python version mismatch between LLDB and scripts inside kernel's dSYM. Python scripts inside your dSYM require Python 2 but Python 2 support has been removed from newer LLDBs. To solve the problem you will have to install older LLDB/Xcode that still has Python 2 support.

So I found the lldb incantation to wait for a process: sudo lldb -n svn -w I then launched svn via my launchagent and indeed lldb attached to it, and indeed the launchagent waited. I waited minutes, then told lldb to continue, and it did, and then the launchagent also finished. But again svn output 'no route to host', and again no permission prompt appeared for me the whitelist svn. I also updated to macOS 15.4, which has not helped.

I tried the solution today and would like to post a correction: Using the --relative-to-command-file or -c flag will then expect a Python module name, which needs to be located directly next to the command file. Demonstrating with examples: $(SRCROOT)/.lldbinit with the following content: command script import --relative-to-command-file ./lldb/type_formatters.py Will result in an error: error: module importing failed: Python does not allow dots in module names: ./lldb/type_formatters $(SRCROOT)/lldb/.lldbinit with the following content: command script import --relative-to-command-file type_formatters Will result in a successful import $(SRCROOT)/.lldbinit with the following content: command script import lldb Will succeed if $(SRCROOT)/lldb is a Python module, denoted with a __init__.py file at $(SRCROOT)/lldb/__init__.py Further python modules then can be imported with command script import which live under $(SRCROOT)/lldb

same problem here. maybe 'lldb-rpc-server' related. during the 2 minutes, 'lldb-rpc-server' take 100% CPU.

(lldb) po retails { item_id = 43; qty = 11; } (lldb) po [retails setObject:@(self.eventID) forKey:(id)@event_id]; error: Execution was interrupted, reason: internal ObjC exception breakpoint(-4).. The process has been returned to the state before expression evaluation. (lldb) po [retails objectForKey:(id)@event_id] nil (lldb)Thank you for the help. It is odd issue. I will debug more.

I've been playing around with this more and noticed that I only see the hitch when I'm running my application with the LLDB debugger connected. If I run my app standalone, it seems to work without a hitch. Could LLDB be interfering with NSEvent dispatch somehow? Is LLDB doing its own processing on my key events before it reaches my app?

Hi Quinn, The image list is a good suggestion. I was just using that other day. I'll try that, and see what lldb reports. This is pure C++, no Swift or ObjC usage. For some of our users, the dylib hotloads and for others not. It's a mix of people mostly on 10.15.7 and XCode 12.2/3. I did the implementation mentioned above of renaming the lib, but it seems like we have a partial reload. So some code hotloads fine, and other code is still pointing to the old lib. Some code at init of the dylib where we crash (with renaming) is reporting the previous numbered dylib in the debugger. This may be an artifact of how Xcode loads the sources once at launch, but when I do hotload, my breakpoints show the new sources. By ODR, do you mean on-demand-resource? We did have those a while back, but I think they're disabled currently. it’s definitely not there after dlclose() on my system. But my system works. Others don't. So I'll get some more info on the machines that don't hotload. after dlopen() (lldb

Just for your happiness: adding my similar issue but with a different kit (StoreKit) and in lldb. (lldb) po product error: expression failed to parse: error: Couldn't lookup symbols: type metadata accessor for StoreKit.Product (lldb) po product.subscription error: expression failed to parse: error: Couldn't lookup symbols: StoreKit.Product.subscription.getter : Swift.Optional (lldb) po product.subscription?.promotionalOffers error: expression failed to parse: error: Couldn't lookup symbols: StoreKit.Product.subscription.getter : Swift.Optional

I generally run a command with arguments using r: % lldb Test773781 (lldb) target create Test773781 ; (lldb) r arg1 #arg2 arg3 ; 0 …/Test773781 1 arg1 The interesting thing here is that LLDB has the right arguments: (lldb) settings show target.run-args target.run-args (arguments) = [0]: arg1 [1]: #arg2 [2]: arg3 It’s just not applying them at launch. Notably, the r command is an alias for process launch: (lldb) help r Launch the executable in the debugger. Syntax: r [] r [] 'r' is an abbreviation for 'process launch -X true --' Note that -X option. Its long name is --shell-expand-args. If you set it to false, it resolves this issue: (lldb) process launch -X false … 0 …/Test773781 1 arg1 2 #arg2 3 arg3 So it seems that LLDB’s shell-like argument expansion is interpreting the # as a comment. Fun times! Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com