LLDB crash

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

I've entered FB21953216 with 2 crash logs attached. Both show multiple threads calling SB (job thread names begin with ProofProcessor). One has 3 jobs and the other has 4. Perfect. I'm glad I asked, as I think I know what the problem is. Going back to my previous message, I said: Also, as a specific detail, how are you actually creating these threads and, in particular, these are standard threads (NSThread/pthread) NOT something fancy like GCD or Swift Async. So, looking at your code, my immediate concern is that you're using NSOperation to run your SBApplication, which means you're using GCD. It looks like the operation itself is a monolithic task attached to one thread (otherwise, this would be REALLY bad) that's destroyed at completion, so I assume that you're creating and destroying the SBApplication for every operation. Theoretically that's relatively safe; however, at a minimum it means you're likely leaking mach ports, which is a risk I'd work VERY hard to avoid. In terms of using your existin

Dear xiewk, Thank you for that crash snippet, however can you please attach a proper .ips file by following the instructions in Posting a Crash Report and Acquiring crash reports and diagnostic logs so we can analyze it accordingly? Thanks, Richard Yeh  Developer Technical Support

[quote='876059022, jzilske, /thread/815493?answerId=876059022#876059022, /profile/jzilske'] the exception reason tripped me up at first: [/quote] Yeah, I’ve been mislead by that in the past. Fortunately, this time I remembered the mantra that we here in DTS chant steadily throughout the day: Always start with a crash report. Always start with a crash report. Almost start with a crash report. … (-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com