Hi there, We see strange crashes on iOS, maybe som...

# kotlin-native

[smbd uknow]

Hi there,
We see strange crashes on iOS, maybe someone faced with something similar before. We’re not sure if it’s connected directly with Kotlin/Native, however we see these stack-traces in Firebase and not able to reproduce the issue locally:
GC Timer thread

void kotlin::RepeatedTimer<kotlin::steady_clock>::Run<kotlin::gc::internal::GCSchedulerDataWithTimer<kotlin::steady_clock>::GCSchedulerDataWithTimer(kotlin::gc::GCSchedulerConfig&, std::__1::function<void ()>)::'lambda'()>(kotlin::gc::internal::GCSchedulerDataWithTimer<kotlin::steady_clock>::GCSchedulerDataWithTimer(kotlin::gc::GCSchedulerConfig&, std::__1::function<void ()>)::'lambda'()&&) + 4373751076
4

void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (*)(kotlin::ScopedThread::attributes, void (kotlin::RepeatedTimer<kotlin::steady_clock>::*&&)(kotlin::gc::internal::GCSchedulerDataWithTimer<kotlin::steady_clock>::GCSchedulerDataWithTimer(kotlin::gc::GCSchedulerConfig&, std::__1::function<void ()>)::'lambda'()&&) noexcept, kotlin::RepeatedTimer<kotlin::steady_clock>*&&, kotlin::gc::internal::GCSchedulerDataWithTimer<kotlin::steady_clock>::GCSchedulerDataWithTimer(kotlin::gc::GCSchedulerConfig&, std::__1::function<void ()>)::'lambda'()&&), kotlin::ScopedThread::attributes, void (kotlin::RepeatedTimer<kotlin::steady_clock>::*)(kotlin::gc::internal::GCSchedulerDataWithTimer<kotlin::steady_clock>::GCSchedulerDataWithTimer(kotlin::gc::GCSchedulerConfig&, std::__1::function<void ()>)::'lambda'()&&) noexcept, kotlin::RepeatedTimer<kotlin::steady_clock>*, kotlin::gc::internal::GCSchedulerDataWithTimer<kotlin::steady_clock>::GCSchedulerDataWithTimer(kotlin::gc::GCSchedulerConfig&, std::__1::function<void ()>)::'lambda'()> >(void*) + 4373751760

GC thread

std::__1::invoke_result<kotlin::gc::ConcurrentMarkAndSweep::ConcurrentMarkAndSweep(kotlin::mm::ObjectFactory<kotlin::gc::ConcurrentMarkAndSweep>&, kotlin::gc::GCScheduler&)::$_2>::type kotlin::ScopedThread::Run<kotlin::gc::ConcurrentMarkAndSweep::ConcurrentMarkAndSweep(kotlin::mm::ObjectFactory<kotlin::gc::ConcurrentMarkAndSweep>&, kotlin::gc::GCScheduler&)::$_2>(kotlin::ScopedThread::attributes, kotlin::gc::ConcurrentMarkAndSweep::ConcurrentMarkAndSweep(kotlin::mm::ObjectFactory<kotlin::gc::ConcurrentMarkAndSweep>&, kotlin::gc::GCScheduler&)::$_2&&) + 4373763056
4

void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (*)(kotlin::ScopedThread::attributes, kotlin::gc::ConcurrentMarkAndSweep::ConcurrentMarkAndSweep(kotlin::mm::ObjectFactory<kotlin::gc::ConcurrentMarkAndSweep>&, kotlin::gc::GCScheduler&)::$_2&&), kotlin::ScopedThread::attributes, kotlin::gc::ConcurrentMarkAndSweep::ConcurrentMarkAndSweep(kotlin::mm::ObjectFactory<kotlin::gc::ConcurrentMarkAndSweep>&, kotlin::gc::GCScheduler&)::$_2> >(void*) + 4373768160

We use Kotlin 1.7.20

[Landry Norris]

Does it tell you what the signal is? Are you getting SIGABRT, SIGSEGV, ENOMEM?

[Landry Norris]

Firebase test labs should show you what devices are affected. Is there a pattern the devices? We’ve seen similar when devices run out of memory at times.

[BenjO]

Hi there 🖖, we just integrated a XCFramework generated using KMP into our iOS app. Only one simple function call, but we notice exactly the same error on 5 real user devices ☝️
Here is a firebase crash occurence. fwiw, our XCFramework is called shared

[BenjO]

We are using Kotlin 1.9.20 . As the stracktrace mentions GC a lot, it seems related to a garbage collector being triggered at repeated interval making the app crash.

@smbd uknow did you manage to fix the issue in your project ?

[smbd uknow]

Oh, I don’t actually remember the outcome. I only recall that it led us to the investigation, where we’ve found that limitedParallelism didn’t work for us in Native code as expected (not sure if it was actually related, but we stopped seeing these crashes in Firebase later and didn’t investigate further), so we replaced usages with newSingleThreadContext
UPD: I’ve just checked our Firebase, no crashes in last 3 months, our Kotlin version is 1.9.10 but I really don’t remember, what was the exact reason, since we did quite a lot of changes in our code back then, sorry

[Landry Norris]

This looks pretty similar to a bug I tracked down a few months ago. I see that you have a timer that runs tasks on a delay. On iOS, if the app is still running code more than 5 seconds after the app leaves the foreground, including the screen being turned off, or the user going to the homescreen, you'll get a SIGABRT on the current thread. The GC should be lifecycle aware as of 1.9.10, but the timer may be triggering things?