Well, that’s an interesting crash. Consider this:
Exception Type: EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid))
The web content process crashed due to a code signing problem. Now look at this backtrace:
Thread 0 Dispatch queue: com.apple.main-thread
0 libGLProgrammability.dylib … glvmOperationMOV + 116 …
1 libGLProgrammability.dylib … glvmInterpretFPTransformFourInner + 3086 …
2 libGLProgrammability.dylib … glvmInterpretFPTransformFour + 3782 …
3 GLRendererFloat … gldLLVMFPTransform + 638 …
4 GLRendererFloat … gldLLVMVecPolyRender + 23252 …
5 GLEngine … gleLLVMVecPrimMultiRender + 10752 …
6 GLEngine … glDrawArrays_GL3Exec + 1016 …
7 libANGLE-shared.dylib … rx::ContextGL::drawArrays(gl::Context con…
8 libANGLE-shared.dylib … gl::DrawArrays(unsigned int, int, int) + …
9 com.apple.WebCore … WebCore::GraphicsContextGLOpenGL::drawArr…
10 com.apple.WebCore … WebCore::WebGLRenderingContextBase::drawA…
11 com.apple.WebCore … WebCore::jsWebGLRenderingContextPrototype…
12 …
13 com.apple.JavaScriptCore … llint_entry + 116352
…
84 com.apple.JavaScriptCore … llint_entry + 116352
85 com.apple.JavaScriptCore … vmEntryToJavaScript + 216
86 com.apple.JavaScriptCore … JSC::Interpreter::executeCall(JSC::JSGlob…
…
This isn’t the usual code signing crash, where the process crashes on launch. Rather, the process has been running for a while and has then crashed. There’s a couple of standard reasons for this:
-
Something invalidate a page of existing code.
-
The process generates code, like with a JIT, and has problems with that.
Frames 85 through 13 suggest that this is the latter but, honestly, I don’t know enough about WebKit to say for sure.
Regardless, I can’t come up with any theories as to how your NE sysex packet tunnel provider could have caused this.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"