Actually, the most common bug I describe in my first message don't
produce any crash report.
Hmmm, that’s surprisingly unhelpful. Who’s displaying that alert? The plug-in itself?
once opened in a text editor, such a report becomes difficult to read...
Yep.
One trick here is to save the file as a .ips and then do a Quick Look in the Finder. That shows the crash report in the traditional human readable format.
I join a new report produced with a plugin of the latter type:
Thanks.
it appears that all of these plugins are protected by iLok keys
Yeah, I suspected DRM was involved.
In your latest crash report I see this:
Exception Type: EXC_BAD_ACCESS (SIGBUS)
…
VM Region Info: 0x12c3a3798 is in 0x12c399000-0x12c4c2000…
…
---> __TEXT 12c399000-12c4c2000 [ 1188K] r-x/rwx …
You’re getting a bus error while access the __TEXT segment, that is, the program’s code. Now consider this:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 bx_console SSL 9000 J … 0x12c399000 + 33486
1 bx_console SSL 9000 J … 0x12c399000 + 30209
2 dyld … dyld4::RuntimeState::notifyObjCInit(dyld4::Loader const*) + 170
3 dyld … dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array&) const +…
4 dyld … dyld4::Loader::runInitializersBottomUpPlusUpwardLinks(dyld4::RuntimeState&) const +…
5 dyld … dyld4::APIs::dlopen_from(char const*, int, void*) + 592
6 CoreFoundation … _CFBundleDlfcnLoadBundle + 149
So the code seems to be doing this to itself. And this:
Error Code: 0x00000007 (invalid protections for user data write)
which suggests it’s trying to write to its own code.
One nice thing about macOS crash reports is that they contain this:
Thread 0 instruction stream:
3b 6e 85 6c b8 31 1e 1d-a2 5f 27 23 f1 07 4a 1f ;n.l.1..._'#..J.
fe cc 1d f0 52 2e 04 62-11 13 8e ef 90 ab 02 6e ....R..b.......n
ab bf 2b 05 39 d2 0d b8-58 e6 2d 39 39 e7 5b 8f ..+.9...X.-99.[.
06 88 45 42 90 ef 8b 45-23 53 a0 c4 51 6e e9 61 ..EB...E#S..Qn.a
8f f4 d0 12 b9 cc 82 7c-a9 69 c2 55 d3 29 18 58 .......|.i.U.).X
e4 9c 2c 85 88 75 d3 90-12 ed e0 13 0a 05 e2 38 ..,..u.........8
[c7]05 c0 24 00 00 00 00-00 00 e9 a1 20 00 00 cc ...$........ ... <==
9f 5c 14 5d 9d 9f 46 c8-5a 41 cc 41 0f 6e 19 5f .\.]..F.ZA.A.n._
07 f8 26 6c 2a d8 c1 43-0d d6 1b 30 da 2f 34 98 ..&l*..C...0./4.
15 a8 70 23 a2 e2 59 db-9a 30 19 ee e9 bb 0b 00 ..p#..Y..0......
00 cc 34 07 a9 be 63 7a-09 c3 b1 fd 29 47 a7 ea ..4...cz....)G..
21 0a 6a 05 f5 d2 d5 75-eb 3d c0 2e 0a 38 c1 66 !.j....u.=...8.f
Disassembling the crash instruction reveals this:
movl $0x0, 0x24c0(%rip)
confirming the above.
DRM systems often perform stunts like this, and that’s one of the reasons why DTS doesn’t support them. There’s a fundamental tension between the goals of the DRM system and long-term binary compatibility. Unfortunately you seem to be an innocent bystander in all of this.
There are a bunch of variables in play here, including at least:
-
App Sandbox
-
Hardened Runtime
-
macOS version
-
Your app
-
The DRMed plug-in
I also suspect that quarantine might play a role.
To make progress you need to tease these apart. Doing that without being able to reproduce the issue is hard, so my first recommendation is that you install macOS 12 and see if you can reproduce the issue locally. If you can, that’ll make the next steps easier. If you can’t, you’re going to have to bounce back and forth with your customer.
After that I suggest that you remove your main app from the equation. If you create a tiny test project that loads this plug-in, does it reproduce the issue? I’d start with an app that has both the App Sandbox and the hardened runtime enabled, just like your main app. If it reproduces the problem, you can then selectively disable either or both and see what you get.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
