“LLDB crash”

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.

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.

This is all I got:(lldb)

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-

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

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.

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

Are you running lldb from the command line? Or are you asking about the LLDB hosted within Xcode’s debugger? Share and Enjoy — Quinn “The Eskimo!” Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

Should this work? Yes. And, indeed, it does work on my machine. I created a test project from the macOS > App template, which defaults to being sandboxed, and I was able to debug it with the command-line LLDB: % codesign -d --entitlements - Test747110.app … [Dict] [Key] com.apple.security.app-sandbox [Value] [Bool] true [Key] com.apple.security.files.user-selected.read-only [Value] [Bool] true [Key] com.apple.security.get-task-allow [Value] [Bool] true % lldb Test747110.app (lldb) target create Test747110.app Current executable set to '…/Test747110.app' (arm64). (lldb) r Process 70203 launched: '…/Test747110.app/Contents/MacOS/Test747110' ``` This is Xcode 15.2 on macOS 14.2.1. Are you sure that sandboxing is the only constraint here? If, for example, your sandboxed app was downloaded from the Mac App Store, you can’t debug that with LLDB. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com