LLDB crash

I discovered the error when I failed to launch the app in TestFlight. I still continue to submit for App Review and obviously, it got rejected. Attached is the crash report. crashlog-8B515F2C-530E-4779-8C09-2EB4845511E5 1.ips The above steps are my troubleshooting to make sure the app is signed using the Apple Distribution certificate and the correct Provisioning Profile. This issue started after I renewed the expired Apple Distribution certificated. So, I suspect the issue is with the certificate. (I have re-generated at least two times.)

Thanks for the crash report. This clearly indicates that your app was up and running when it crashed. The backtrace of the crashing thread looks like this: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_platform.dylib … sys_icache_invalidate + 40 1 libllvmlite.dylib … llvm::sys::Memory::protectMappedMemory(llvm::sys::MemoryBlock const&, unsigned int) + 356 2 libllvmlite.dylib … LLVMPY_TryAllocateExecutableMemory + 92 3 libffi.dylib … ffi_call_SYSV + 80 4 libffi.dylib … ffi_call_int + 1220 5 _ctypes.cpython-312-darwin.so … _ctypes_callproc + 1384 6 _ctypes.cpython-312-darwin.so … PyCFuncPtr_call + 212 7 Python … _PyObject_Call + 164 That suggests you’re hitting a hardened runtime incompatibility. See Resolving Hardened Runtime Incompatibilities. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='793324021, neha24, /thread/793324, /profile/neha24'] FB18834450 [/quote] That’s definitely the right path forward here. However, I looked at your bug report and it’s kinda short on details. It would be helpful if you attached: The sysdiagnose log from the iPhone that’s actually triggering the crash. A sysdiagnose log from the Mac taken immediately after seeing the crash. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='793353021, naftaly, /thread/793353, /profile/naftaly'] What are my options if I want to iterate over loaded images … within a signal handler? [/quote] There are no valid options for this. None of the dynamic linker APIs you need are async signal safe [1]. For more background, see Implementing Your Own Crash Reporter. However, you might be able to make some progress by doing this work outside of signal handler and stashing it in a global. If you search the above-mentioned post for atomic and offline, you’ll find my advice for that. Having said that, I must reiterate a key point from that post: If you’re building your own crash reporter, please don’t. There’s no way to do that in a way that’s simultaneously reliable, binary compatible, and sufficient to debug complex problems. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] And this is not just a theoretical concern. I’ve seen many watchdog crash reports

When I use device below iOS 15，in the dyld phase, it will cause crash。 and it will requires u add frameworks in the Build Phases -> LInk Binary With Libraries。 I add 7 frameworks in my project and set it as Optional. otherwise, we are geting Symbol not found error. My environment is macOS15.5, Xcode Beta 3, iOS12。

I am not asking for help fixing a crash. I did that by commenting out one line of code where I was asking SwiftData to sort ModelA results on a title string from an associated ModelB object. ModeB has a one to many association to ModelA and must exist before any ModelA objects are created BUT CloudKit requires that you specify the relationships between these two models as Optional. Therefore when I tried to sort ModelA results by a Title in ModelB I needed to declare the property as a force unwrapped title of ModelB in the SortDescriptor. It would be ludicrous to try to show the actual code so that you can follow everything. Suffice it to say that this SortDescriptor was accepted by the compiler, and gave me exactly what I wanted when I ran the App either in a Simulator or on a device that downloaded the app from Xcode. BUT when the app was uploaded to the App Store and then downloaded from TestFlight the App would immediately crash with no useful error pointing to the problem. Bottom line i

Hi DTS, Thanks! I have been using Developer ID Application certificate to sign the code. I did not post the whole crash report before. Please check the attachment, which does contain the full crash report this time. Thanks! 2025_july_16th_crash_report.txt

Not entirely sure what your issue is here. You say something crashes, but you don't explain what the crash is, so it's not possible to see whether you're doing something wrong or if there is a genuine issue in Apple's code. You haven't provided any code whatsoever, so I really can't give you any help at all. Can you provide some code that explains your issue properly?

The only ‘obvious’ thing I can think of here is that you’re trying to run App Store distribution-signed locally. That doesn’t work in general. See Don’t Run App Store Distribution-Signed Code. If this is Developer ID signed code then that doesn’t apply, and there’s something else in play. You posted a crash report snippet. Is that the full crash report? Or is there more? If so, please post the full report as a text attachment. See Posting a Crash Report for detailed advice. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I want to make sure we’re talking about the same thing here. Please post an example crash report and point out the line number of concern. See Posting a Crash Report for advice on how to post a crash report. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I don't see details in the crash report (such as a Termination Description) that could guide me to address the issue. So I would appreciate it if you can give me some insight on what could be causing this. The key detail here is: Termination Reason: FRONTBOARD 0xbaadca11 Which means: 0xbaadca11 (3131951633) — pronounced bad call The operating system terminated the app for failing to report a CallKit call in response to a PushKit notification. I assume that since the app was awakened by a VoIP push, those background notifications won't count towards the iOS restriction of not getting too many background pushes: Correct. There isn't any restriction or limitation on the number of VoIP pushes that can be sent to an app and, indeed, the main reason the CallKit reporting requirements were introduced is that VoIP pushes were being widely abused and we didn't want to artificially limit push volume. However... Those pushes are delivered within 30 seconds after the call starts. ...I think using PushKit for thi

Hi I am encountering the same crash. Have you found a fix for this?