I'm trying to po an object in lldb and I get the following:(lldb) po fooerror: reference to 'foo' is ambiguouscandidate found by name lookup is 'foo'candidate found by name lookup is 'foo'I have seen references to this error back in Xcode 4.x but nothing recent. Is there a fix for this? I'm using Xcode Version 9.2 (9C40b) and ObjC.
Search results for
LLDB crash
29,555 results found
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
I think you have to close XCode and reopen, not only playground to clear everything.There is no equivalent of Clean build folder for playground (because there is no build) !).I tried the following in a playground, on macOS 10.13.6 with Xcode Version 10.1 beta 3 (10O45e)let x = 3 x += 5 print(x)It crashed (normal) with the message at top:The LLDB RPC server has crashed. The crash is located in ~/Library/Logs/DiagnosticReports and has a prefix of 'lldb-rpc-server'. Please file a bugI changed let to var and everything ran OK.
Topic:
Developer Tools & Services
SubTopic:
Xcode
Tags:
Hello, I was able to reproduce the same LLDB RPC server crash. This is unexpected behavior so please send us a bug report with the Feedback Assistant.
Topic:
Graphics & Games
SubTopic:
Metal
Tags:
Or if you're unable to provide the full crash log, can you at least provide the UUID of the DVTInstrumentsFoundation.framework in that process (eg: `image list` at the lldb prompt)
Topic:
Developer Tools & Services
SubTopic:
Xcode
Tags:
Same issue here after I updated from macOS 15.3 to 15.4 and Xcode 16.2 to 16.3 Message from debugger: The LLDB RPC server has crashed. You may need to manually terminate your process. The crash log is located in ~/Library/Logs/DiagnosticReports and has a prefix 'lldb-rpc-server'. Please file a bug and attach the most recent crash log. Couldn't find the Objective-C runtime library in loaded images. This error never occurred on my local development machine before the upgrade! This is particularly annoying because debugging is no longer possible in this state and breakpoints no longer work.
Topic:
Developer Tools & Services
SubTopic:
Xcode
Tags:
I type in the terminal: lldb$ lldbTraceback (most recent call last): File <string>, line 1, in <module> File /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/Python/lldb/__init__.py, line 98, in <module> import sixImportError: No module named sixTraceback (most recent call last): File <string>, line 1, in <module>NameError: name 'run_one_line' is not definedTraceback (most recent call last): File <string>, line 1, in <module>NameError: name 'run_one_line' is not definedTraceback (most recent call last): File <string>, line 1, in <module>NameError: name 'run_one_line' is not definedTraceback (most recent call last): File <string>, line 1, in <module>NameError: name 'run_one_line' is not definedTraceback (most recent call last): File <string>, line 1, in <module>NameError: name 'run_one_line' is not definedTraceback (most recent call last): File <string>, line 1, in <module>NameE
Thanks for the advice. 🙂Comically, my app does *not* crash when run from lldb or even when attached to lldb. I can use my app fine, crash-free, while under lldb. As soon as I detach lldb from my app and perform actions in it, I get this crash (please disregard the other earlier crash report with 'voucher_xref_dispose', that issue appears to be resolved). This is the same crash I get when launched from the Dock:Thread 6 Crashed:0 libxpc.dylib 0x00007fff701c4da4 xpc_release + 61 libxpc.dylib 0x00007fff701c7869 _xpc_dictionary_node_free + 622 libxpc.dylib 0x00007fff701c4b3f _xpc_dictionary_insert + 1813 libxpc.dylib 0x00007fff701c9253 xpc_dictionary_set_uint64 + 414 libnetwork.dylib 0x00007fff6e7c2d90 nw_path_copy_dictionary_for_agent_with_generation + 8645 libnetwork.dylib 0x00007fff6e734cda nw_path_snapshot_path + 4266 libnetwork.dylib 0x00007fff6e715fc6 nw_path_evaluator_evaluate + 21027 libnetwork.dylib 0x00007fff6e714
Topic:
Developer Tools & Services
SubTopic:
Xcode
Tags:
Here's a simple C++ program that echoes its arguments... #include int main(int argc, char* argv[]) { for (int i=0; i ./test arg1 #arg2 arg3 0 ./test 1 arg1 2 #arg2 3 arg3 Running under lldb gives this... > lldb ./test arg1 #arg2 arg3 (lldb) target create ./test Current executable set to '/Users/richard/Work/test' (arm64). (lldb) settings set -- target.run-args arg1 #arg2 arg3 (lldb) run Process 6138 launched: '/Users/richard/Work/test' (arm64) 0 /Users/richard/Work/test 1 arg1 Process 6138 exited with status = 0 (0x00000000) I get the same if I quote the arguments, or if I add them to the run line. Stepping into main() we see the argv and args values are as though we only had the first argument. If I quote the second argument and add an initial space #arg1 then it works. I first saw this on an M1 running Sequoia 13.1. It am now on OS 13.3. lldb --version lldb-1600.0.39.109 Apple Swift version 6.0.3 (swiftlang-6.0.3.1.10 clang-1600.0.30.1)
I think LLDB is red herring here. When your app crashed in App Review, did they send you a crash report? If so, can you post an example here? Following the guidance in Posting a Crash Report. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
Topic:
Developer Tools & Services
SubTopic:
Xcode
Tags:
I'm trying to use a technique we use on Linux to get a stack trace of a process that gets in trouble. We fork a debugger in batch mode in a child process to get the back trace of the parent. When I run this, lldb hangs in the attach to the parent process. And since lldb cannot attach to lldb, there's no way for me to see what's blocking lldb in the attach to the parent. Attached is a simple program that demonstrates the problem. Manually running lldb from a shell with the same arguments gets the stack trace. Is there some way around this hang? #include #include #include #include #include #include static void runChild(pid_t parent) { tconst char *lldb = /usr/bin/lldb; tconst char * args[8]; tchar pidstr[16]; tsnprintf(pidstr, sizeof(pidstr), %d, (int) parent); targs[0] = lldb; targs[1] = --no-lldbinit; targs[2] = --batch; targs[3] = -p; targs[4] = pidstr; targs[5] = --one-line; targs[6] = thread backtrace all; targs[7] = NULL; terrno
When some part of the code is not working as expected, you may have some faults in other parts of your code. In this case, you may need to check all the parts where landmarks appears. One more, when your app quit unexpectedly, please show all the messages shown in the debug console.
Topic:
UI Frameworks
SubTopic:
SwiftUI
Tags:
Has anyone has this error when trying to run a watchOS 2 app on a connected phone and watch:Warning: Error creating LLDB target at path '/Users/user/Library/Developer/Xcode/DerivedData/app-cuurdvsnbtcffcgnbrqkwlimkdjj/Build/Products/Debug-iphoneos/App WatchKit Extension.appex'- using an empty LLDB target which can cause slow memory reads from remote devices.Would love to know if there's a fix to this.
Broke for me after the update to Big Sur 11.4. Tried every fix in this thread to no avail, about to jump on Apple Support. My message icon shows an incoming text, but when I try and open Messages on my Macbook Pro it ***** out with Messages Quit Unexpectedly.
Topic:
App & System Services
SubTopic:
General
Tags:
We are updating our macOS projects for Universal binaries and our two main apps fail to debug in Xcode 12.2 (on Big Sur), but I can use lldb from the command line to run the built app. When I try to run the app in the debugger in Xcode I get this error: Warning: Error creating LLDB target at path 'my app path'- using an empty LLDB target which can cause slow memory reads from remote devices. error: failed to launch '2687' -- LLDB provided no error string I assume the number is the PID, it changes each time I try to run the debugger. Not sure what to do.
hello, i can't fix this error displayed in the return line(lldb)int main(int argc, char *argv[]) { return UIApplicationMain(argc, argv, nil, NSStringFromClass([PoutremultivueAppDelegate class])); }