Crash: WebCore::LayerRepresentation::makePlatformLayerTypeless(CALayer*)

Hi, I was wondering if I could get some insight on this crash. it seems that the app was on the background for a couple of hours, and crashed upon returning to the foreground. We have some parts of the app with WKWebView, I'm assuming they put the app to the background while on the screen that has the webview. I couldn't find much of the "makePlatformLayerTypeless".

Here's the full logs.

Thanks!

Thanks for the crash report.

it seems that the app was on the background for a couple of hours, and crashed upon returning to the foreground.

It’s hard to be sure of that last part, but it’s certainly the case that the app has been running for a while:

Date/Time:           2022-04-18 08:07:38.3680 -0400
Launch Time:         2022-04-17 22:18:00.9262 -0400

I couldn't find much of the makePlatformLayerTypeless.

That’s part of the WebKit code that underlies WKWebView. If you really want to dig into that, you can find the source code here.

Looking at that, combined with the following:

Exception Type:  EXC_CRASH (SIGSEGV)
Exception Codes: 0x0000000000000000, 0x0000000000000000

suggest a memory management problem. That could be a bug anywhere, but given the context I suspect that it’s in WebKit or some other framework, not in your code. Still, that’s just a guess. Having said that, it never hurts to run your app with the standard memory debugging tools to see if they can help make the problem more reproducible.

One other interesting thing I saw in the crash report is this:

Thread 15:
0  libsystem_kernel.dylib … mach_msg_trap + 8
1  libsystem_kernel.dylib … mach_msg + 76 …
2  libdispatch.dylib      … _dispatch_mach_send_and_wait_for_reply + 540 …
3  libdispatch.dylib      … dispatch_mach_send_with_result_and_wait_for_re…
4  libxpc.dylib           … xpc_connection_send_message_with_reply_sync + …
5  Foundation             … __NSXPCCONNECTION_IS_WAITING_FOR_A_SYNCHRONOUS…
6  Foundation             … -[NSXPCConnection _sendInvocation:orArguments:…
7  CoreFoundation         … ___forwarding___ + 1128 …
8  CoreFoundation         … _CF_forwarding_prep_0 + 96
9  LocalAuthentication    … __64-[LAClient evaluatePolicy:options:uiDelega…
10 LocalAuthentication    … __47-[LAClient _performSynchronous:callId:fina…
11 libdispatch.dylib      … _dispatch_call_block_and_release + 32 …

It looks like someone is in the middle of doing a Local Authentication operation at the time of the crash. Any chance that’s your code?

Finally, this:

Thread 17:
0   libsystem_kernel.dylib  … mach_msg_trap + 8
1   libsystem_kernel.dylib  … mach_msg + 76 (mach_msg.c:119)
2   wwwwwwvvvvvvv           … exception_server_thread + 188 (PLCrashMachExceptionServer.m:674)
3   libsystem_pthread.dylib … _pthread_start + 148 (pthread.c:891)
4   libsystem_pthread.dylib … thread_start + 8

indicates you’re running a third-party crash reporter. The crash report you posted looks pretty clean, so it’s probably not causing problems. However, my general advice is to not use a third-party crash reporter, for the reasons I explain in Implementing Your Own Crash Reporter.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

It looks like someone is in the middle of doing a Local Authentication operation at the time of the crash. Any chance that’s your code?

Yes, if they have biometry enabled in the app, once they return to the app and are logged out, then we immediately prompt the biometry check. This is why I thought that maybe they left the phone while at a screen that has a WKWebview, then the app timed out, so when they came back to the app, they were prompted to sign in again and that's when the biometry checks kicked in. Are you able to see in thread 15 if the LocalAuthentication finished its processes or was interrupted?

Additionally, I will try the "standard memory debugging tools", although I've used it in the past without much success.

Are you able to see in thread 15 if the Local Authentication finished its processes or was interrupted?

Frame 5 makes it very clear that the thread is blocked waiting for LA to respond to its XPC request.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Crash: WebCore::LayerRepresentation::makePlatformLayerTypeless(CALayer*)
 
 
Q