User Profile

We are seeing mysterious crashes in our app when running on the Apple Silicon machines using Rosetta. The crash is coming from Apple's runtime and dyld libraries, and always has the same kind of stack, but without much useful information. All have the same pattern of 5 stack frames, the bottom being dyld, and then 4 in runtime, but all just addresses, no idea what symbols are being called Sometimes the offset values are the same, other times they are not. When you group them together, we have at least two sets of stacks; but close enough that it appears the same root issue. Only these two libraries appear to be loaded, so perhaps it's a crash on launch before things are adequately setup, or something weird happens during the crash and we are only getting a small part of the picture captured in the .crash, or some corruption happens All are in Apple Silicon machines Some are on macOS 11, and some on macOS 12, so it's not a Monterey beta issue They are all crashing for reason Code Signature Invalid, but this seems unreliable, if indeed we can launch the app afterwards without issue, which appears to be the case (based on log reports we've received). Here is a typical example (with some app info redacted): Version: ??? Code Type: X86-64 (Translated) Parent Process: ??? [1] User ID: 503 Date/Time: 2021-08-06 14:38:06.408 +0200 OS Version: macOS 11.5.1 (20G80) Report Version: 12 Time Awake Since Boot: 21000 seconds Time Since Wake: 15000 seconds System Integrity Protection: enabled Crashed Thread: 0 Exception Type: EXC_BAD_ACCESS (Code Signature Invalid) Exception Codes: 0x0000000000000032, 0x0000000106675000 Exception Note: EXC_CORPSE_NOTIFY Termination Reason: Namespace CODESIGNING, Code 0x2 kernel messages: VM Regions Near 0x106675000: VM_ALLOCATE (reserved) 106671000-106675000 [ 16K] r--/r-- SM=NUL reserved VM address space (unallocated) --> mapped file 106675000-107ff9000 [ 25.5M] r-x/rwx SM=COW Object_id=695dd8f1 mapped file 107ff9000-107ffd000 [ 16K] r-x/r-x SM=COW Object_id=6aaf57f1 Thread 0 Crashed: 0 runtime 0x00007ffdffe9ac40 0x7ffdffe96000 + 19520 1 runtime 0x00007ffdffea3df4 0x7ffdffe96000 + 56820 2 runtime 0x00007ffdffea35ec 0x7ffdffe96000 + 54764 3 runtime 0x00007ffdffe9a440 0x7ffdffe96000 + 17472 4 dyld 0x000000020683f000 0x20683f000 + 0 Thread 0 crashed with ARM Thread State (64-bit): x0: 0x0000000106675000 x1: 0x000000030d81b730 x2: 0x0000000000000218 x3: 0x0000000000000012 x4: 0x0000000000000004 x5: 0x0000000001984000 x6: 0x0000000000000000 x7: 0x0000000000000a40 x8: 0x0000000000000007 x9: 0x0000000000000012 x10: 0x0000000106675fff x11: 0x0000000100000000 x12: 0x0000000000000000 x13: 0x0000000000000000 x14: 0x0000000000000000 x15: 0x000007d900018601 x16: 0x00000000000000c5 x17: 0x000000000220bef3 x18: 0x000000030d81b073 x19: 0x000000030d81b730 x20: 0x000000030d81aa78 x21: 0x0000000106675000 x22: 0x0000000000000004 x23: 0x0000000106675000 x24: 0x0000000000000003 x25: 0x0000000000000001 x26: 0x000000030d81ab90 x27: 0x000000020683f000 x28: 0x000000030d823960 fp: 0x000000030d81aa20 lr: 0x00007ffdffea267c sp: 0x000000030d81a9b0 pc: 0x00007ffdffe9ac40 cpsr: 0x20000000 far: 0x0000000106675000 esr: 0x92000006 Binary Images: 0x20683f000 - 0x2068dafff dyld (852.2) <57DB2053-BFD5-3683-97C6-F1DB2A1F1D09> /usr/lib/dyld 0x7ffdffe96000 - 0x7ffdffec5fff runtime (203.58) <52A2E5D0-FAA3-34EF-8BB7-07F73718C034> /usr/libexec/rosetta/runtime External Modification Summary: Calls made by other processes targeting this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by all processes on this machine: task_for_pid: 0 thread_create: 0 thread_set_state: 0 VM Region Summary: ReadOnly portion of Libraries: Total=1048K resident=0K(0%) swapped_out_or_unallocated=1048K(100%) Writable regions: Total=19.8M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=19.8M(100%) VIRTUAL REGION REGION TYPE SIZE COUNT (non-coalesced) =========== ======= ======= STACK GUARD 56.0M 1 Stack 8176K 1 VM_ALLOCATE 10.5M 1 VM_ALLOCATE (reserved) 1132K 3 reserved VM address space (unallocated) __DATA 288K 4 __DATA_CONST 32K 1 __LINKEDIT 272K 4 __TEXT 816K 2 mapped file 4.8G 11 =========== ======= ======= TOTAL 4.9G 28 TOTAL, minus reserved VM space 4.9G 28 Any help or guidance is much appreciated. I cannot say for sure this is an Apple issue, as I have no way to reproduce it reliably, either in our app or another. But it seems doubtful it's a bug in our app. Thank you!

Greetings. With Xcode 11 .crash files can be opened in Xcode and appear as if you were in an active debug session by showing the stack in the debug pane. However, clicking on any of the symbols doesn't seem to do anything, even if I know my code is sync-ed up to the version of the app that crashed. I also surprisingly have not been able to find much of any info on how this feature works, and how to use it, either through Apple's documentation or otherwise. Can anyone point me in some useful direction regarding this feature? Thanks.

I work on a macOS app which uses the CoreGraphics APIs to retrieve the whole screen as an image, or the various windows of an application. This is for a screen sharing feature. Notably, we use CGWindowListCreateImageFromArray. We occasionally run into an issue where Apple's WindowServer process starts to consume a lot of CPU (close to 100%) and the whole system becomes incredibly sluggish, almost unusable.The problem persists even when you stop the screen sharing and we aren't calling the APIs anymore, until you terminate the app.Has anyone who has worked with the CoreGraphics APIs, have knowledge of how they connect with the WindowServer process to give some insight into what we might be doing that perturbs the WindowServer in these cases?A spindump of the system sometimes shows that indeed our app and others are waiting on the WindowServer, which is taking up almost all the time of the spindump in its main thread. However, other times, it's not quite as clear cut. Seems like some kind of "soft" deadlock, since the WindowServer isn't completely frozen (since the UI is still somewhat accessible).Any help is much appreciated! Thanks.

I am working on a macOS project that uses hardware acceleration for video encoding, using ************. I have tried controlling the bitrate using these properties.kVTCompressionPropertyKey_AverageBitRate kVTCompressionPropertyKey_DataRateLimitsBut after many attempts it still frequently overshoots the target bitrate.Is kVTCompressionPropertyKey_DataRateLimits respected on macOS?When I use VTSessionCopySupportedPropertyDictionary to get the supported properties on my compression session, DataRateLimits shows up in the dictionary, and I have set it on the compression session without error. But then if I try to actually get the value of it usingCFTypeRef value = nullptr; result = VTSessionCopyProperty(m_compressionSessionRef, (__bridge CFStringRef)key, kCFAllocatorDefault, &amp;valwhere key is DataRateLimits, as taken from the dictionary, it returns an error that the property is unsupported.But on iOS, it returns successfully.This seems pretty serious, and does not appear limited to my machine. If it's truly not supported, that would help explain the volatility of my encoding bitrate. However, in months of working on this project and researching ************, I have not seen anything about this not being supported by the hardware encoder on macOS. I would think such a defect would be a big issue. Does anyone have any insight here? Thank you!