IINA crashes with 'Code Signature Invalid' #3551
Comments
|
I have encountered this as well with development builds using Xcode 13.1 under macOS 12.0.1 on a MacBook Pro with the M1 Max chip. Because it was during development I made a mental note to look at it later. When I saw this issue I decided I'd keep an eye out for it. Just crashed on me again. The crashed thread shows the same location as in the crash report posted above: This was running a debug build outside of Xcode. I don't remember having encountered this while running from Xcode. I was running iina-cli from terminal. I just executed the same command line again and IINA worked. A "Code Signature Invalid" under Monterey issue has recently been filed against Node: nodejs/node#40827 Similar behavior of not consistently failing. In poking around the net I also found a report of Wireshark crashing with such an error running under a Monterey Beta version. This is smelling like some sort of thread race condition in Apple's checking of code signatures. Checking the signing of the official IINA 1.2.0 release under Monterey shows no errors. Validating Code Signatures |
|
I dug into this some today and came up empty. This is what I checked. In the crashed thread the LuaJIT library is calling the mpv method static void load_file(lua_State *L, const char *fname)
{
struct script_ctx *ctx = get_ctx(L);
MP_DBG(ctx, "loading file %s\n", fname);
struct bstr s = stream_read_file(fname, ctx, ctx->mpctx->global, 100000000);
if (!s.start)
luaL_error(L, "Could not read file.\n");
if (luaL_loadbuffer(L, s.start, s.len, fname))
lua_error(L);
lua_call(L, 0, 1);
talloc_free(s.start);
}I believe this stacktrace from the crashing thread: Indicates This Apple document: Porting Just-In-Time Compilers to Apple Silicon Discusses requirements that are also required on Intel Macs. But there is this new requirement for Apple silicon:
Could that be an issue? Does Luajit handle that? This is the Luajit code: /* Synchronize data/instruction cache. */
void lj_mcode_sync(void *start, void *end)
{
#ifdef LUAJIT_USE_VALGRIND
VALGRIND_DISCARD_TRANSLATIONS(start, (char *)end-(char *)start);
#endif
#if LJ_TARGET_X86ORX64
UNUSED(start); UNUSED(end);
#elif LJ_TARGET_IOS
sys_icache_invalidate(start, (char *)end-(char *)start);
#elif LJ_TARGET_PPC
lj_vm_cachesync(start, end);
#elif defined(__GNUC__) || defined(__clang__)
__clear_cache(start, end);
#else
#error "Missing builtin to flush instruction cache"
#endif
}For macOS #if __APPLE__
// On Darwin, sys_icache_invalidate() provides this functionality
sys_icache_invalidate(start, end - start);I didn't find anything that could explain the random "Code Signature Invalid" failures. |
|
Got this 4 times today. I'll test if building mpv with regular lua instead of luajit helps |
|
That sounds like a good experiment. |
|
Running |
|
@su-thomas Thanks very much for reporting your experience. Unfortunately your report adds to the confusion surrounding this failure. Did you encounter this under macOS 12, or some other version? I'm still looking into this one but I keep finding other problems while trying to reproduce it. I wasn't quite ready to post an analysis as I still can't explain why this failure has popped up now. Here is what I know so far... The analysis of the crash above appears to indicate that macOS is rejecting the execution of Lua code that has been compiled on the fly by OpenResty's LuaJIT library. That should have to do with the application's entitlements. IINA is built with the Allow Execution of JIT-compiled Code Entitlement,
The @saagarjha has pointed out that the OpenResty LuaJIT library is not using the This Firefox bug report, macOS startup crash "Code Signature Invalid", indicates a different entitlement is required if <!-- Firefox does not use MAP_JIT for executable mappings -->
<key>com.apple.security.cs.allow-jit</key><false/>
<!-- Firefox needs to create executable pages (without MAP_JIT) -->
<key>com.apple.security.cs.allow-unsigned-executable-memory</key><true/>Apple's documentation for the Allow Unsigned Executable Memory Entitlement,
This Apple forum thread: App not launching after signing with hardened runtime, involves Lua and in the second post the user appears to have encountered the same failure as being discussed here. The solution that worked was to use the Apple developer relations commented on this thread that it is highly desirable to follow the Apple recommended JIT techniques so that the I was hoping to gather a little more evidence before asking the LuaJIT project for their thoughts on this issue. Given all that I'm confused as to why resigning the application cleared the problem for you. |
|
@low-batt My apologies for the lack of context. I was having the same issue (crash message Code Signature Invalid) on every launch. However this is on macOS 11, MBP 13" 2020 (Intel) and with a build with MPV 0.34.0. After resigning the application, the app launches without crash. |
|
Interesting. If you building locally can you rebuild, not sign, and confirm you still experience the crash. If so, then subsitute this file for "iina/IINA.entitlements": <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.security.cs.allow-unsigned-executable-memory</key>
<true/>
<key>com.apple.security.cs.disable-library-validation</key>
<true/>
</dict>
</plist>Rebuild. Not sign. See if the crash still reproduces. I replaced the key When editing entitlements inside Xcode that is shown as "Allow Unsigned Executable Memory". |
|
@low-batt yes, building locally with upgraded mpv deps. |
|
Thank YOU for running that test! That appears to confirm some of the above findings. Still some aspects of this behavior are confusing, like why has this come up now, and why does resigning also clear the problem? I will dig into it a bit more to see if I can explain any of that. I will be asking the OpenResty LuaJIT project about following Apple's best practices and adding use of the |
This commit will replace the entitlement "com.apple.security.cs.allow-jit" with "com.apple.security.cs.allow-unsigned-executable-memory" in the IINA.entitlements file. This is required because the OpenResty LuaJIT library is not following Apple's best practices for JIT compilers that allow use of the more restrictive entitlement. This has been reported in this LuaJIT issue: Code Signature Invalid crash using com.apple.security.cs.allow-jit openresty/luajit2#145
This commit will replace the entitlement "com.apple.security.cs.allow-jit" with "com.apple.security.cs.allow-unsigned-executable-memory" in the IINA.entitlements file. This is required because the OpenResty LuaJIT library is not following Apple's best practices for JIT compilers that allow use of the more restrictive entitlement. This has been reported in this LuaJIT issue: Code Signature Invalid crash using com.apple.security.cs.allow-jit openresty/luajit2#145
This commit will replace the entitlement "com.apple.security.cs.allow-jit" with "com.apple.security.cs.allow-unsigned-executable-memory" in the IINA.entitlements file. This is required because the OpenResty LuaJIT library is not following Apple's best practices for JIT compilers that allow use of the more restrictive entitlement. This has been reported in this LuaJIT issue: Code Signature Invalid crash using com.apple.security.cs.allow-jit openresty/luajit2#145
This commit will replace the entitlement "com.apple.security.cs.allow-jit" with "com.apple.security.cs.allow-unsigned-executable-memory" in the IINA.entitlements file. This is required because the OpenResty LuaJIT library is not following Apple's best practices for JIT compilers that allow use of the more restrictive entitlement. This has been reported in this LuaJIT issue: Code Signature Invalid crash using com.apple.security.cs.allow-jit openresty/luajit2#145
This commit will replace the entitlement "com.apple.security.cs.allow-jit" with "com.apple.security.cs.allow-unsigned-executable-memory" in the IINA.entitlements file. This is required because the OpenResty LuaJIT library is not following Apple's best practices for JIT compilers that allow use of the more restrictive entitlement. This has been reported in this LuaJIT issue: Code Signature Invalid crash using com.apple.security.cs.allow-jit openresty/luajit2#145
This commit will replace the entitlement "com.apple.security.cs.allow-jit" with "com.apple.security.cs.allow-unsigned-executable-memory" in the IINA.entitlements file. This is required because the OpenResty LuaJIT library is not following Apple's best practices for JIT compilers that allow use of the more restrictive entitlement. This has been reported in this LuaJIT issue: Code Signature Invalid crash using com.apple.security.cs.allow-jit openresty/luajit2#145
This commit will replace the entitlement "com.apple.security.cs.allow-jit" with "com.apple.security.cs.allow-unsigned-executable-memory" in the IINA.entitlements file. This is required because the OpenResty LuaJIT library is not following Apple's best practices for JIT compilers that allow use of the more restrictive entitlement. This has been reported in this LuaJIT issue: Code Signature Invalid crash using com.apple.security.cs.allow-jit openresty/luajit2#145
This commit will replace the entitlement "com.apple.security.cs.allow-jit" with "com.apple.security.cs.allow-unsigned-executable-memory" in the IINA.entitlements file. This is required because the OpenResty LuaJIT library is not following Apple's best practices for JIT compilers that allow use of the more restrictive entitlement. This has been reported in this LuaJIT issue: Code Signature Invalid crash using com.apple.security.cs.allow-jit openresty/luajit2#145
|
Could be related to this https://developer.apple.com/documentation/security/updating_mac_software ? |
|
The Apple article Updating Mac Software cited is related in that it is discussing a way to trigger a "Code Signature Invalid" failure, the failure at the root cause of this issue. However that article is about how to avoid triggering this failure when updating an application. That is not the case at hand. IINA is a user interface for the command line movie player mpv. Both mpv and IINA support the ability to customize the behavior of the player by embedding scripts written in the programming language Lua. See the LUA SCRIPTING section of the mpv manual for details. Even if an IINA user does not customize IINA with such scripts Lua is still being used because the mpv player library implements some operations using Lua scripts. Applications can execute scripts using a software Interpreter. Using a software interpreter is a fine approach for scripts that are not frequently executed. However if a script is going to be run many times it is more efficient to use Just-in-time compilation. IINA is using OpenResty's LuaJIT library to compile Lua scripts at runtime. This means that IINA through the LuaJIT library is generating unsigned code at runtime. Special requirements related to code signing for applications that use JIT are discussed in the Apple article Porting Just-In-Time Compilers to Apple Silicon. As per that document IINA is using Allow Execution of JIT-compiled Code Entitlement. The failure occurs because the LuaJIT library is not following the requirements specified in that Apple document. This has been reported against the LuaJIT library in issue openresty/luajit2#145. Until the LuaJIT library is fixed IINA will have to use Allow Unsigned Executable Memory Entitlement. That proposed change is in PR #3592. Although that PR has not been merged yet it is considered a must fix for the next release. |
This commit will replace the entitlement "com.apple.security.cs.allow-jit" with "com.apple.security.cs.allow-unsigned-executable-memory" in the IINA.entitlements file. This is required because the OpenResty LuaJIT library is not following Apple's best practices for JIT compilers that allow use of the more restrictive entitlement. This has been reported in this LuaJIT issue: Code Signature Invalid crash using com.apple.security.cs.allow-jit openresty/luajit2#145
This commit will replace the entitlement "com.apple.security.cs.allow-jit" with "com.apple.security.cs.allow-unsigned-executable-memory" in the IINA.entitlements file. This is required because the OpenResty LuaJIT library is not following Apple's best practices for JIT compilers that allow use of the more restrictive entitlement. This has been reported in this LuaJIT issue: Code Signature Invalid crash using com.apple.security.cs.allow-jit openresty/luajit2#145
This commit will replace the entitlement "com.apple.security.cs.allow-jit" with "com.apple.security.cs.allow-unsigned-executable-memory" in the IINA.entitlements file. This is required because the OpenResty LuaJIT library is not following Apple's best practices for JIT compilers that allow use of the more restrictive entitlement. This has been reported in this LuaJIT issue: Code Signature Invalid crash using com.apple.security.cs.allow-jit openresty/luajit2#145
This commit will replace the entitlement "com.apple.security.cs.allow-jit" with "com.apple.security.cs.allow-unsigned-executable-memory" in the IINA.entitlements file. This is required because the OpenResty LuaJIT library is not following Apple's best practices for JIT compilers that allow use of the more restrictive entitlement. This has been reported in this LuaJIT issue: Code Signature Invalid crash using com.apple.security.cs.allow-jit openresty/luajit2#145
This commit will replace the entitlement "com.apple.security.cs.allow-jit" with "com.apple.security.cs.allow-unsigned-executable-memory" in the IINA.entitlements file. This is required because the OpenResty LuaJIT library is not following Apple's best practices for JIT compilers that allow use of the more restrictive entitlement. This has been reported in this LuaJIT issue: Code Signature Invalid crash using com.apple.security.cs.allow-jit openresty/luajit2#145
This commit will replace the entitlement "com.apple.security.cs.allow-jit" with "com.apple.security.cs.allow-unsigned-executable-memory" in the IINA.entitlements file. This is required because the OpenResty LuaJIT library is not following Apple's best practices for JIT compilers that allow use of the more restrictive entitlement. This has been reported in this LuaJIT issue: Code Signature Invalid crash using com.apple.security.cs.allow-jit openresty/luajit2#145
|
The fix (a workaround) in PR #3592 has been merged into the develop branch. |
|
Closing. Fixed in IINA 1.3.0. |
System and IINA version:
Expected behavior:
Don't crash
Actual behavior:
Crash report:
mpv log:
Steps to reproduce:
Just run IINA and it may crash when starting
How often does this happen?
Some time. I can't reproduce it consistently
The text was updated successfully, but these errors were encountered: