Desktop app crashes completely with Namespace Codesigning exception

Targets macOS
1

This is from a test application driving a color measurement device that’s inside a thread class. The latter is to decouple longer taking actions from the main thread, so that no GUI blockage can take place.
The API for the instrument has a callback and an API method to register this one. Which, in first tests, used to work. But only here, not on customer’s computer. I somehow managed to recreate the hard crash they run into. It will appear whenever the callback is triggered, and in form of an

Exception Type: EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid))
Exception Codes: UNKNOWN_0x32 at 0x0000000106ff8000
Exception Codes: 0x0000000000000032, 0x0000000106ff8000

Termination Reason: Namespace CODESIGNING, Code 2 Invalid Page

VM Region Info: 0x106ff8000 is in 0x106ff8000-0x106ffc000; bytes after start: 0 bytes before end: 16383
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
CG image 106ff4000-106ff8000 [ 16K] rw-/rwx SM=PRV
—> VM_ALLOCATE 106ff8000-106ffc000 [ 16K] r-x/rwx SM=PRV
CoreAnimation 106ffc000-107000000 [ 16K] rw-/rwx SM=PRV

which I cannot explain to myself. Sounds like there would be issues with code signing, but the exception will not disappear even if I notarise the app with AppWrapper. I am using DeclareCallbackMBS for the callback (pinging @Christian_Schmitz in case this could somehow be connected, which I doubt. I also tried a shared method with the same exception.) Any ideas for this?

Thread 12 Crashed:
0   ???                           	       0x106ff8000 ???
1   i1Pro3                        	       0x11a89c81c 0x11a800000 + 641052
2   i1Pro3                        	       0x11a804390 0x11a800000 + 17296
3   libsystem_pthread.dylib       	       0x1844942e4 0x18448d000 + 29412
4   libsystem_pthread.dylib       	       0x18448f0fc 0x18448d000 + 8444

Thread 13:
0   libsystem_pthread.dylib       	       0x18448f0e8 0x18448d000 + 8424


Thread 12 crashed with ARM Thread State (64-bit):
    x0: 0x000000011e0b0e10   x1: 0x0000000000000001   x2: 0x0000000000000000   x3: 0x00006000026dc05d
    x4: 0x0000000000000001   x5: 0x00000000e32b9003   x6: 0x0000000000000022   x7: 0x000000011a98a91e
    x8: 0x0000000106ff8000   x9: 0x0000000000000002  x10: 0x0000000000000000  x11: 0x0000000000000002
   x12: 0x0000000000000000  x13: 0x0000000000000000  x14: 0x00000000e36b9003  x15: 0x00000000e34b8873
   x16: 0x000000018448ee18  x17: 0x0000000000000003  x18: 0x0000000000000000  x19: 0x000000011aa058f0
   x20: 0x000000011a9e3cc0  x21: 0x0000000000000000  x22: 0x0000000000000000  x23: 0x0000000000000000
   x24: 0x0000000000000000  x25: 0x0000000000000000  x26: 0x0000000000000000  x27: 0x0000000000000000
   x28: 0x0000000000000000   fp: 0x000000016fbdef30   lr: 0x000000011a89c424
    sp: 0x000000016fbdee10   pc: 0x0000000106ff8000 cpsr: 0x80001000
   far: 0x0000000106ff8000  esr: 0x8200000f (Instruction Abort) Permission fault
2

It says Thread 12 crashed.

  1. Are you using preemptive threads in your app?
  2. Is ThreadCallbackMBS preemptive thread safe?
  3. Is all of the executable code in your bundle signed with your signing certificate?
3

Thank you, Greg. Yes, that’s why I cited Thread12. And yes, it’s inside a preemptive thread. DeclareCallBackMBS is explicitly meant for callbacks on threads, so I would think it is thread safe.
About the signing: I hope that AppWrapper does so :wink:

4

There’s a finder extension from objective-see.com for checking signing integrity.

5

Oh and…

Please make sure this callback object stays alive, e.g. stored in a global property. When the object is released and the callback later invoked, the application will crash.

When you code sign on macOS, you may need to use the entitlement for just-in-time compiler and for unsigned executable memory, e.g. the com.apple.security.cs.allow-unsigned-executable-memory
entitlement.

There’s your code signing reference. Did you add those entitlements?

I’ll also add that having the second entitlement sounds like it severely limits the value of the signing. Apple has this to say:

Including this entitlement exposes your app to common vulnerabilities in memory-unsafe code languages. Carefully consider whether your app needs this exception.

1 Like
6

Sure I did.

That’s an excellent point and could be the reason! I’ll check it. Thank you!

7

I added a note from Apple above

8

Thank you again. Yes, but it looks like this is the only way to make it work. I had the idea building as Intel would solve the problem but got corrected when customer did tests …
So far, looking good for me but let’s see what customer finds.

1 Like
9

It’s worth thinking about whether the declare you’re working with returns its call on the main thread or not. When Xojo announced preemptive threads back in the fall, I explicitly asked if we could now “catch” callbacks on non-main threads and William said no. I don’t know what MBS is doing under the hood, but the fact that it says it is thread-safe does not necessarily mean that it handles callbacks on non-main threads. We’d need @Christian_Schmitz to answer that.

10

It is thread safe in the thing that it receives the callback and then dispatches a method call to the main thread.

But Ulrich has a code signature problem. Not sure about it.

1 Like
11

@Greg_O Let’s see what customer says about the newest build. Could very well have been the missing entitlements.

12

Thank you, Greg. That fixed it. Also some spurious calibration errors. I thought using a library would rather be a binary thing: It works, or it doesn’t. That some parts don’t work sometimes(!) was new to me.