“LLDB crash”

[WillBProg3245 emailed me their crash report.]Well, that’s an interesting crash you’ve got there. I had a look at your crash report and it didn’t reveal anything new, so I then started poking around in your core.% lldb -c core.719 (lldb) target create --core core.719 Core file '/Users/quinn/Desktop/core.719' (x86_64) was loaded. (lldb) thread list Process 0 stopped … thread #10: … libxpc.dylib`xpc_release + 6 … … (lldb) thread select 10 … (lldb) disas -f libxpc.dylib`xpc_release: 0x7fff65659d9e <+0>: testb $0x1, %dil 0x7fff65659da2 <+4>: jne 0x7fff65659ddd ; <+63> -> 0x7fff65659da4 <+6>: movq (%rdi), %rax …As you can see, the program has crashed referencing RDI at +6. So what’s in RDI:(lldb) p/x $rdi (unsigned long) $0 = 0xe2160458f3753a00Whoah, that does not look even close to a valid pointer. Heap pointers on modern versions of macOS typically look like 0x00006000_xxxxxxxx. Moreover, all poin

Consider this: % lldb (lldb) p/x 78133671 (int) $0 = 0x04a839a7 (lldb) p/x 1152921500311879699 (long) $1 = 0x0fffffff00000013 I’m not sure what attribute your code is fetching, but it’s definitely not an inode number. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thank you @DTS Engineer. These are great details! I've follow-up questions to be sure using Xcode Cloud doesn't turn out in being a mistake. If I archive only using Xcode Cloud (with the option to include symbol enabled), can the Xcode Organizer show symbolicated crash logs for app builds that are more than 30 days old (the archive availability window)? For example, a crash for an app version released 6 months ago. Can you elaborate on the significant debugging capabilities using LLDB that aren't possible without them. What does that mean? Basically, what I want is to be able to see the crash logs in Xcode Organizer, and open them in Xcode Project at the commit I used to archive the app to see what caused the crash and to fix it. I hope it's clear. Thank you, Axel

So, yeah, third-party crash reporters are a bad idea, especially when trying to deal with hard problems. I talk more about that in Implementing Your Own Crash Reporter. I presume that you have some additional metadata that makes it clear that you’re crashing in __ulock_wait, because nothing in that crash report indicates that’s the case. Regardless, you’re not crashing there, at least not really. Consider this: (lldb) disas -n __ulock_wait libsystem_kernel.dylib`__ulock_wait: 0x18bf739b0 <+0>: mov x16, #0x203 ; =515 0x18bf739b4 <+4>: svc #0x80 0x18bf739b8 <+8>: b.lo 0x18bf739d8 ; <+40> Due to the way crash reports are generated, the __ulock_wait + 8 in your crash reports means that the actual PC was at <+4>, that is, the system call instruction (svc) itself. It’s unlikely that crashed your process. Rather, your process was blocked — possibly deadlocked — and something else crashed it. What t

We have tried BOTH ways (on Sequoia/arm64): without lldb, that is serveur.out with lldb, that is lldb server.out Most of the post shows the second call (with lldb). We are NOT creating an app (in the macOS sense) at the moment. We start our programs from the Terminal (Serveur on 1 window, Client on another window, both in the same machine or not -- communication is done by sockets) ==> Since then, we have tried to change from clang to another C++ compiler. Still problems with gcc The problem disappears with c++ ! We are now sure that the problem comes from the amr64 version of clang, because exactly the same code runs without problems on Sequoia/x86_64/clang.

Hokay, let's run it again with a breakpoint on -[UINavigationController popToViewController:animated:]. We push via a list row, then pop. Interestingly, the entire animation completes before -popToViewController:animated: is invoked, as though SwiftUI is actually doing that whole thing itself—which is interesting.However, when it's done we see that method being invoked on a UINavigationController at 0x7fbd13035200, and it's being asked to pop to an instance of UIHostingController<_VariadicView_Children.Element> at 0x7fbd1782e940. The navigation controller has this to say about its content:(lldb) po [$rdi viewControllers] <__NSSingleObjectArrayI 0x60000139c6b0>( <_TtGC7SwiftUI19UIHostingControllerVVS_22_VariadicView_Children7Element_: 0x7fbd1782e940> ) (lldb)In other words, it only contains that one item—the same one to which it's being asked to pop. So it seems that the error is less likely about emptying the stack, but about asking to go back to a view that isn't in the st

That's really weird because I have the same thing with underscores in the lldb output and in this box. Looks like it is stripped if it's not inside a code block. Pasting it again here within a code block. I'm using the base64 encoder on NSData and making it URL safe as you've shown. x: EUA2cFR9ZrGJozbkwYeyBrbrG3p4ChHBQu_sWem2sgM y: n6WQz7uMkIALgLM5xriANs5VXKy_2Q71jetoI6Pzojk ==== DON'T USE THIS (BELOW) SINCE UNDERSCORES ARE STRIPPED ===== (lldb) po xbytes EUA2cFR9ZrGJozbkwYeyBrbrG3p4ChHBQusWem2sgM (lldb) po ybytes n6WQz7uMkIALgLM5xriANs5VXKy2Q71jetoI6Pzojk

Yes, though lldb allows a few more options than gdb. You can provide commands to run either before or after the file provided on the command line is read in. You can also provide single lldb commands. You can provide more than one file or single command, and they will get run in the order they appear on the command line. Anyway, try running lldb --help in Terminal and you will get a full description of the various options.

Hi, we do try to see forum posts too, but yes filing feedback is the best way to be seen, and also to know when your requests have been addressed in an Xcode release. We are aware of lldb-eval. There has been a proposal to incorporate its functionality into lldb. See https://discourse.llvm.org/t/rfc-data-inspection-language/69893 As mentioned in that forum post, lldb-eval itself doesn't support Natvis. The post mentions that some Natvis tooling exists which makes use of lldb-eval, for performance. it's far simpler to edit and write than the lldb rules and python scripting. Do you edit and write the Natvis directly with XML? Or are there high level tools for writing Natvis that hide the XML syntax? I have looked at Natvis, and found myself thinking the opposite, that it must be difficult to get over the learning curve of writing debug formatters in XML. If you send a feedback, please share its URL here. -- Dave

I have (possibly) good news. SKTestSession.failTransactionsEnabled has been depreacted since iOS17, but it behaves strangely on iOS17. (lldb) po session.failTransactionsEnabled false (lldb) po session.failTransactionsEnabled = false 0 elements (lldb) po session.failTransactionsEnabled true We may work around this issue by not setting a value for this variable. // before session.failTransactionsEnabled = false // after if #unavailable(iOS 17.0) { session.failTransactionsEnabled = false } In iOS17 we probably need to use simulatedError(forAPI:).

[quote='797102022, DTS Engineer, /thread/760029?answerId=797102022#797102022'] If you only want to look at the app, rather than run it, you can ignoer the whole thing: [/quote] So I ran lldb ~/Library/Developer/Xcode/Archives/2024-07-12/MyApp macOS 12.07.2024, 20.43.xcarchive/Products/Applications/MyApp.app To translate the addresses from the crash report to lldb, it wasn't sufficient to subtract the binary image base address, but I found some help at Symbolicating with LLDB. By running lldb image list which outputs [ 0] 2521131E-2080-387D-B96E-8DB6AA18E011 0x0000000100000000 ~/Library/Developer/Xcode/Archives/2024-07-12/MyApp macOS 12.07.2024, 20.43.xcarchive/Products/Applications/MyApp.app/Contents/MacOS/MyApp /System/Volumes/Data/~/Library/Developer/Xcode/Archives/2024-07-12/MyApp macOS 12.07.2024, 20.43.xcarchive/dSYMs/MyApp.app.dSYM/Contents/Resources/DWARF/MyApp [ 1] 37BBC384-0755-31C7-A808-0ED49E44DD8E 0x00000001800b8000 /usr/lib/dyld ... I found out that th

On my 2014 Mac Mini, the download and installation process appeared to work flawlessly to completion, although it took more than an hour (perhaps because the Mini is slow). But when it was done, About This Mac still says it's build 18A326g, not 18A326h.I shut the Mini down and then booted it up again. Still 18A326g. But when I ran Software Update in System Preferences again, it claimed that the Mini is up to date and won't let me update again. Very confusing.Then a minute later UI???Kit quit unexpectedly. I clicked the button to reopen it, and all appears to be ok now except it's still 18A326g.