“LLDB crash”

Hello. I tested using Xcode Version 26.2 (17C52) on macOS 26.2 (25C56) using your code with the following color format files and I was unable to reproduce a crash. Can you provide a copy of the image file you are using for testing? Formats I tried: RGB_NoneSkipFirst_8bit 8 bits/component, 32 bits/pixel RGBX format (no alpha, skip first byte) sRGB color space AlphaInfo: kCGImageAlphaNoneSkipFirst RGB_NoneSkipLast_8bit 8 bits/component, 32 bits/pixel XRGB format (no alpha, skip last byte) sRGB color space AlphaInfo: kCGImageAlphaNoneSkipLast RGB_AlphaPremultFirst_8bit 8 bits/component, 32 bits/pixel ARGB format with premultiplied alpha sRGB color space AlphaInfo: kCGImageAlphaPremultipliedFirst RGB_AlphaPremultLast_8bit 8 bits/component, 32 bits/pixel RGBA format with premultiplied alpha sRGB color space AlphaInfo: kCGImageAlphaPremultipliedLast RGB_AlphaPremultLast_16bit 16 bits/component, 64 bits/pixel RGBA format with premultiplied alpha sRGB color space AlphaInfo: kCGImageAlphaPremultipliedLast RGB

The Xcode team is here! Thanks for reporting this, I'm seeing the lost prompt as well when starting a new conversation. The crash sounds quite unfortunate and is not something I've seen. A bug report would be great, especially if you have reproducible steps or a screen recording. Even the crash report would be very informative. Thank you for reporting!

That's a no-go. Jobs just have to run until they are done. There are dozens, if not hundreds, of pieces of data that are built and used along the way. Some of them are hogs that will run for 3 hours. Long running is a very relative concept, as there's a huge difference between 3 hours” -> “3 days” -> “3 months. Strictly speaking, it's not even REALLY about time itself, at least not on its own. There are basically a few different goals I'd be looking at here: Isolating your work activities from each other so that they can't interfere with each other. Reducing the complexity of the long running component such that it's easier to test/validate/etc. Reducing the execution timeline to something that can reasonably be tested (“week” vs “month”). The first goal basically solves the immediate crash you're looking at. That is, it's fairly clear that the crash involves some kind of interaction between multiple SBApplication threads, so it can't happen when there's only one thread. Moving to the

or the SB/AE world that fails So, in the process of writing up the message that follows this one, I actually had a breakthrough about what might be involved in triggering this crash. That is, I don't think it's necessarily CAUSING the crash, but I think it is part of the situation that creates the crash. Here is the crashing thread on all three crashes you sent: 0 com.apple.AE 0x1a7d970cc isMachReplyOutstanding(short) + 92 1 com.apple.AE 0x1a7d89b80 absolveReturnID(short) + 92 2 com.apple.AE 0x1a7d8994c AEEventImpl::AEEventImpl(unsigned int, unsigned int, AEDesc const*, short, int) + 100 3 com.apple.AE 0x1a7d85bfc AECreateAppleEvent + 416 What absolveReturnID actually does is generate the random 16-bit ID used when using kAutoGenerateReturnID, which is then checked as unused by calling isMachReplyOutstanding. However, the interesting detail here is that absolveReturnID also has a fixed cache of the last (~64) IDs, so it can just skip those IDs instead of checking f

Thanks @DTS Engineer, I have already read that documentation. You advised that I should enable all the settings. However, I noticed that for Memory Tag Pure Data, the description states that “it may incur a performance overhead”. I am therefore inclined not to enable it. Regarding Enable Soft Mode for Memory Tagging, the description states that “memory tagging faults will not crash and will be logged instead”. I am inclined to leave this disabled, as I would prefer the application to crash so that I can receive a crash report and potentially fix the issue. I am not entirely sure what is meant by logging in this context, would this appear in the Xcode console when running in Debug mode? As you are knowledgeable about AppKit and Mac computers, may I ask if you would mind looking at my other post about StoreKit 2? I am at my wits’ end, as I would like to ship the Cocoa app using the API but cannot because it is not behaving as expected. I am tempted to submit a code-level support reque

[Different DTS engineer here; I’m picking up this thread because it’s directly aligned with my area of expertise.] [quote='876554022, Tenjikato, /thread/815899?answerId=876554022#876554022, /profile/Tenjikato'] it does not appear in Xcode Organizer. [/quote] Right. The issue here is that you have a third-party crash reporter installed and it’s failing to preserve the Apple crash report. Let’s look at the backtrace in your first post: Crashed: com.apple.main-thread 0 KSCrash … ksmemory_notifyUnhandledFatalSignal + 12 1 KSCrash … handleSignal + 100 2 libsystem_platform.dylib … _sigtramp + 56 3 libsystem_kernel.dylib … mach_msg2_internal + 76 4 libsystem_kernel.dylib … mach_msg_overwrite + 428 5 libsystem_kernel.dylib … mach_msg + 24 6 CoreFoundation … __CFRunLoopServiceMachPort + 160 7 CoreFoundation … __CFRunLoopRun + 1188 8 CoreFoundation … _CFRunLoopRunSpecificWithOptions + 532 9 GraphicsServices … GSEventRunModal + 120 10 UIKitCore … -[UIApplication _run] + 792 Frames 10 through 3

Thank you for your guidance! Unfortunately, we have been unable to reproduce the crash internally, and it does not appear in Xcode Organizer. All occurrences were reported from production devices, so we do not have access to the corresponding .ips files. However, we can provide the full stack trace from Firebase Crashlytics if that would be helpful. a79d64a106f9d569e54661f0c2e361fd_crash_session_140bafc49a6e4ef487d22d01806fc1b7_DNE_0_v2_stacktrace.txt a79d64a106f9d569e54661f0c2e361fd_crash_session_ea0e80b874de47bdb671e7b530afa446_DNE_0_v2_stacktrace.txt

That's interesting about the difference between NSOperation and NSThread as far as Mach ports go. I watched the # ports in Activity Monitor as I ran a job, and it certainly doesn't climb as each job runs. It goes from initially in the 300s to the low 500s right when the job starts, and stays around there, even after the job ends, and then I run the same job 2 or 3 more times without quitting. Well, that's the joy of Mach port leaks... you never REALLY know what you'll get. So, as some broader background here, the actual issue here isn't really about the thread API itself- ultimately, both APIs are using pthreads and the special pthread GCD uses aren't really different than standard pthreads. The real issue here is that you don't actually own the thread and the assumptions AppleEvents/ScriptingBridge were built around. Both of those APIs predate GCD (by many, many years) and are built around the assumption that they'll be used on a long-running thread that's running its own runloop, as that was basically THE p

I am testing my iOS app on iOS 18. I performed 50 tests, and in 43–44 of them, the app successfully detects beacons, relaunches in the background, and continues BLE communication. Testing how? What are the details of the process you're actually using to test this? That is, are you: Artificial Testing” -> Laying the phone on a desk next to the beacon and toggling the beacon (or shielding the phone) on/off to simulate entry and exit. VS. Real World Testing” -> Carrying the phone around in your pocket and seeing what happens. Beyond that, what are the broader parameters of the test itself? How far is the device from the beacon? How long is the device exposed to the beacon? What's the broader use case you're trying to implement? Most importantly, what, if anything, do you know about EXACTLY what was happening when the failure occurred? I want to understand why beacon triggers are inconsistent in iOS. What are the common reasons behind iOS not relaunching the app for beacon events, and what factors affect re

That's interesting about the difference between NSOperation and NSThread as far as Mach ports go. I watched the # ports in Activity Monitor as I ran a job, and it certainly doesn't climb as each job runs. It goes from initially in the 300s to the low 500s right when the job starts, and stays around there, even after the job ends, and then I run the same job 2 few more times without quitting. This app can run for days or weeks. It can process anywhere from a few to probably a couple hundred jobs a day. Yes, each job creates a new NSOperation and a new SBApplication, which are both destroyed when each job finishes. Each job can call into the SBApplication hundreds or thousands of times. The rate at which each script is run can be as fast as possible, given the speed at which InDesignServer will process each script. At times there is barely any application code going on between each script. (E.g. ask InDesign for the range of some text, tell InDesign to do something with that range of text, tell InDesign to repl

Thanks for the post, my guess here is your process is called KSCrash? The crash file should be posted as an attachment to be able to analyze. Kindly submit a comprehensive crash report, adhering to the guidelines outlined in Posting a Crash Report. https://developer.apple.com/forums/thread/688669 As you said, the error typically indicates that your application is trying to access memory that has already been deallocated or is otherwise invalid. Although you mentioned using Address Sanitizer, double-check your configuration to ensure it's correctly enabled. Sometimes, specific project settings might prevent tools from working as expected. If you're using collections that hold objects, ensure they are not being modified. Use or breakpoints to trace object lifetimes and ensure they are being deallocated when expected. This can help pinpoint where the object is being released prematurely. If you're using third-party libraries, ensure they are up-to-date, as bugs in libraries can manifes