FrontBoardServices crashes at app launch

Consider the crashing thread’s backtrace:

Thread 0 Crashed:
0   libsystem_kernel.dylib  … __pthread_kill + 8 (:-1)
1   libsystem_pthread.dylib … pthread_kill + 268 (pthread.c:1670)
2   libsystem_c.dylib       … abort + 180 (abort.c:118)
3   libc++abi.dylib         … abort_message + 132 (:-1)
4   libc++abi.dylib         … demangling_terminate_handler() + 320
5   libobjc.A.dylib         … _objc_terminate() + 160 (objc-exception.mm:5…
6   libc++abi.dylib         … std::__terminate(void (*)()) + 16 (:-1)
7   libc++abi.dylib         … std::terminate() + 56 (:-1)
8   libdispatch.dylib       … _dispatch_client_callout + 40 (object.m:563)
9   libdispatch.dylib       … _dispatch_block_invoke_direct + 264 (queue.c…
10  FrontBoardServices      … __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__…

Your app is crashing due to an unhandled language exception. Specifically, frames 7 through 5 are all typically seen in such situations.

Frame 8 is interesting. That code is part of Darwin; see here. Dispatch has logic to catch language exceptions thrown by the blocks that it runs and terminate the process.

So, it seems that FrontBoard is running a block on one of its queues (frame 10), that’s travelled through some Dispatch machinery (frames 8 and 9), which has called the block, which has thrown an exception, after which Dispatch has deliberately terminated the process.

Normally in situations like this there’s a Last Exception Backtrace section in the crash report. The most likely reason that’s missing is that this was a C++ exception. Those don’t generate this info; see this thread for more on that.

There’s two possibilities here. The first is that this exception was thrown by system code, in which this is most definitely a bug. System code should not be throwing language exceptions like this.

It’s also possible that this exception was thrown by your code. Do you use a lot of C++ in your product?

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

Thanks for your reply @eskimo,

No, we don't use a lot of C++ in our product. Do you have any recommendations in this case? I will try to add more logs in our code for the next release, but the crash rate is increasing and unfortunately, I don't know where to start looking.

Regards

No, we don't use a lot of C++ in our product.

OK. That suggests — although it’s not a guarantee — that this is being thrown by the system.

Do you have any recommendations in this case?

I’d start by filing a bug. Ideally that’d include a sysdiagnose log taken shortly after seeing the issue. Are you in touch with any of your users having this problem? Can you find one who’s up for grabbing a sysdiagnose log?

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

Thanks for your replay @eskimo,

Unfortunately, we are not in touch with one of these users to ask them for sysdiagnose log, but I will try.

I wanted to check something with you...

As part of this version, we are also getting Peak Memory and Memory at Suspension metrics:

I was checking debugging gauges and as soon as I put the app on background the memory consumption increases abruptly:

So, using instruments for allocations I found most of the memory is used by CoreUI and the stack trace looks pretty similar to the crash log (but in this case doesn't crash):

I wonder if the app could be running out of memory and the system kills it as soon as the user opens it.

Also, this is happening mostly on iOS 16.5 devices per our metrics:

Regards!

I wonder if the app could be running out of memory and the system kills it as soon as the user opens it.

Well, anything’s possible but I don’t see a lot of evidence for that. The crash report clearly indicates that you crashed due to an unhandled language exception. It’s possible that a resource shortage might be triggering this, but that’s a pretty unusual symptom. Most resource shortage issues result in either the app being jetsam’d or something that’s not a language exception, like dereferencing nil.

Having said that…

I was checking debugging gauges and as soon as I put the app on background the memory consumption increases abruptly:

I’ll admit that’s kinda weird.

the stack trace looks pretty similar to the crash log

Right, but all FrontBoard is done from that serial queue and thus has a backtrace rooted in __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__. In this case it looks like FrontBoard is doing pretty typical view rendering stuff.

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

Hello there, I'm facing the same issue here. Do you have happen to have any updates/solutions for it?

Thank you