LLDB crash

[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.

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:).

This is all I got:(lldb)

I ran your code on my Intel machine and, while it doesn’t crash, it produces incorrect results: total using c++ = 355 total shirts using asm = 527584 I suspect that’s because you posted the “working but wrong” version rather than the “correct but crashes” version (-: The error you’re hitting is because you’re accessing memory out of bounds. I’m hardly an expert on Intel assembly language but the most obvious problem here is that you’re using register esi. Apple dropped 32-bit Intel support a while back, so any modern machine only runs 64-bit code. That means you need to use the 64-bit variant of this register, that is, rsi. So this line: lea esi, [b] produces a truncated value. If I set a breakpoint after that line, compare the value in esi: (lldb) p/a $esi (unsigned int) $0 = 0x000080b0 and the actual address of b: (lldb) p/a &b[0][0] (int *) $2 = 0x00000001000080b0 b This truncation means that, when you attempt to access the address, you hit the 4 GiB of unmapped memo

Thank you for the suggestions. And here is the Bug number 29038737.This approach is unlikely to yield a reliable solution. There are just too many ways that things can go wrong. This is also what I am quite concerned about the idea. The removable disk example is a very good one that can be considered as one of the cases that the helper is unexpectedly removed. For these cases, I can have the application check and re-install (re-bless) the helper with prompt the auth at the startup though this bothers the user for the auth again. Are there any other side effects about this idea? The most important thing I was worried about is that whether the solution could have any undefined behavior since it is not a standard approach.

Hello, I cannot debug more, because I would need to compile a debuggable version of libmalloc. My findings so far: I enter in https://opensource.apple.com/source/libmalloc/libmalloc-317.140.5/src/malloc.c.auto.html free Then, it enters in find_registered_zone When inside find_registered_zone, I lose myself. I know that tcmalloc library is called because I can see that the malloc library asks the size (which is translated in the call to tcmalloc::mz_size). Then, tcmalloc (here: https://github.com/gperftools/gperftools/blob/master/src/libc_override_osx.h#L108) correctly calculates the size and returns 128 When back to the malloc library, I see that more code on find_registered_zone is executed, but at some point, instead of the tcmalloc zone, the default zone is returned and then free_definite_size is called on that. But... default_zone is the tc_malloc one, which doesn't have free_definite_size, and crash! ... (lldb) thread step-inst Process 95351 stopped * thread #1, queue = 'com.apple.main-

Could you capture a types log by putting log enable lldb types -f /tmp/types.log into ~/.lldbinit-Xcode an relaunching Xcode and reproducing the error? If it doesn't show up in the LLDB console the types usually contains the underlying error. You can either post it here, or look through it yourself and read the blocks around LogConfiguration closely. They show how the Swift and Clang compilers that are embedded into LLDB were initialized for your app. Usually they contain a hint why things go wrong.

[quote='796681022, Nickkk, /thread/760029?answerId=796681022#796681022, /profile/Nickkk'] were you thinking of a particular command that creates disassemblies with symbol names [/quote] I generally do this stuff in LLDB. The trick there is to make sure you’re debugging the right build. You’re on the Mac, and it’s actually pretty straightforward here: Just run LLDB from the command line and target your built binary: % lldb /path/to/your.app … (lldb) r … Alternatively, run the app from Finder and then, in Xcode, choose Debug > Attach to Process. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Hi there,After the information you gave me I checked things out a bit further.It appears to be when the Map is loaded.I am getting differing error messages. Please see below.2015-07-06 18:00:00.078 USAShoppingMalls[4481:60b] -[__NSArrayM length]: unrecognized selector sent to instance 0x200a2910(lldb)2015-07-06 18:01:57.798 USAShoppingMalls[4490:60b] -[VGLResourceImpl length]: unrecognized selector sent to instance 0x1d1a9e90(lldb)Everything loads into the array correctly but it crashes when the mapview is displayed.I corrected a code error of 2 off ;; after setting the region.span.longitudeDelta = 7.0f;;.I also get different results depending on whether I load the Mapview and then the Annotations or the Other way around.I am not fully aware of what should be loaded first or if it should be loaded in ViewDidLoad or [super viewDidLoad];Thanks Ossie

There are a couple of things that you could be referring to:If you have a swift app, cmd-shift-Y is the default keybinding to open the Console where the output of print() will go.If you pause in the debugger, LLDB understand swift code. From there, you can type repl to get an interactive swift session:(lldb) repl1>Just typing xcrun swift from Terminal.app will give you the same thing. It will still be lldb, but it will jump directly into repl mode for you to play around with Swift.Is that what you had in mind?

Once the XCTRunner has unexpectedly quit dialog is displayed it remains for all following integrations as the Aqua session is not killed. Stopping and starting Xcode Server doesn't close the Aqua session. I am guessing resetting Xcode Server will but that means losing your bots and customizations. Restarting your server will also likely fix the issue but if the server is a remote machine with a drive using filevault then you need someone to be available to restart it.I manually killed various Aqua related processes on the command line whilst Xcode Server was stopped, started Xcode Server and after a few minutes I was able to perform integrations again.

add a new button in the Debugger pane and be able to modify program stateThe problem here is the GUI. LLDB has a sophisticated extension architecture, supporting aliases for simple stuff and Python scripting for accomplishing complex tasks. These work in LLDB from both the command line (via the lldb command) and within Xcode. However, Xcode does not have any mechanism for loading extensions that tweak its GUI. One possibility here is to host that GUI outside of Xcode, in a floating palette say. The tricky part here is managing the IPC between the GUI and the LLDB extension, although that’s probably doable.Share and Enjoy — Quinn “The Eskimo!” Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com