https://kotlinlang.org logo
#kotlin-native
Title
# kotlin-native
a

ankushg

08/19/2022, 7:33 AM
We’re running into a strange issue in release iOS builds with the new memory model. Doesn’t happen in debug builds. When a user opens/closes a particular screen multiple times, on the ~12th try, we trigger the GC, and it crashes the app. The stracktrace looks something like:
Copy code
Crashed: GC thread
0  QuizletSharedKotlin            0x919294 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&&) + 1292
1  QuizletSharedKotlin            0x91a214 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*) + 112
2  libsystem_pthread.dylib        0x19ac _pthread_start + 148
3  libsystem_pthread.dylib        0xe68 thread_start + 8
It’s super hard for us to create a minimal reproduction of this, but in case it’s relevant, we’ve been able to repro this with: • Kotlin 1.7.10 and 1.7.20-Beta • SqlDelight 1.5.3 and 2.0.0-alpha03 • kotlinx.coroutines 1.6.4 (without the
-native-mt
suffix) • KMP-NativeCoroutines 0.12.6-new-mm Any tips on how to narrow this down?
r

Rick Clephas

08/19/2022, 7:45 AM
Are you using
0.12.6
or
0.12.6-new-mm
of KMP-NativeCoroutines? Just to be safe you should use the
-new-mm
if you aren’t using the
-native-mt
coroutines.
a

Alexey Belkov [JB]

08/19/2022, 8:39 AM
cc @svyatoslav.scherbina
s

svyatoslav.scherbina

08/19/2022, 9:01 AM
I’m afraid this is not enough for us to debug the issue.
The stracktrace looks something like:
Is it from 1.7.20-Beta or 1.7.10? This might help us at least to understand which part of the code crashes.
When a user opens/closes a particular screen multiple times, on the ~12th try, we trigger the GC, and it crashes the app.
What happens if you trigger the GC sooner?
a

ankushg

08/19/2022, 3:12 PM
@Rick Clephas We are using the new-mm version — updated the post! @svyatoslav.scherbina the stacktrace shown is from 1.7.10. I can also repro with 1.7.20-Beta for a very similar stacktrace. How can we manually trigger the kotlin GC to run? What additional info would be useful to track down the issue?
j

Jeff Lockhart

08/19/2022, 3:21 PM
How can we manually trigger the kotlin GC to run?
Copy code
kotlin.native.internal.GC.collect()
s

svyatoslav.scherbina

08/19/2022, 3:40 PM
What additional info would be useful to track down the issue?
A full crash report would be useful. Is it ios_arm32 or ios_arm64? Is there a chance you could share a crashed binary with us?
a

ankushg

08/19/2022, 5:36 PM
Here’s the full stacktrace from an arm64 device: https://pastebin.com/PcVKdiuh The binary is the release version of our app in the App Store (Quizlet) 😅 I’ll try manually invoking the GC at various times and see what happens
s

svyatoslav.scherbina

08/22/2022, 8:03 AM
The binary is the release version of our app in the App Store (Quizlet) 😅
Does that mean that you can’t share an actual binary file with us? 🙂 We need it to figure out which code actually crashes.
y

Yekta

12/04/2022, 11:45 AM
Any updates on this issue? I happen to get the same error in the same circumstances, too. And I don’t even force the garbage collection. It occurs in a random order in the app that I can only reproduce on the repetitive triggering of the call-site.
Copy code
frame #0: 0x000000010db51f24 YektaSariogluSharedDetail`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&&) + 2568
s

svyatoslav.scherbina

12/05/2022, 6:01 PM
@Yekta It depends. We fixed one of the problems. Which Kotlin version do you use? Could you please provide a full crash report? This particular stack trace fragment doesn’t mean that this is the same issue, neither provides any clue on the problem.
m

marty-suzuki

01/31/2023, 9:57 AM
I’ve been facing same issue with
Kotlin 1.7.20
. It caused only release build framework.
Copy code
Thread 2
#0	(null) in std::__1::invoke_result<kotlin::gc::ConcurrentMarkAndSweep::ConcurrentMarkAndSweep(kotlin::mm::ObjectFactory<kotlin::gc::ConcurrentMarkAndSweep>&, kotlin::gc::GCScheduler&)::$_2>::type kotlin::Scop... ()
#1	(null) in std::__1::invoke_result<kotlin::gc::ConcurrentMarkAndSweep::ConcurrentMarkAndSweep(kotlin::mm::ObjectFactory<kotlin::gc::ConcurrentMarkAndSweep>&, kotlin::gc::GCScheduler&)::$_2>::type kotlin::Scop... ()
#2	(null) in 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, kotl... ()
#3	(null) in _pthread_start ()
#4	(null) in thread_start ()
We fixed one of the problems.
Has this issue fixed by
1.7.21
or greater?
s

svyatoslav.scherbina

01/31/2023, 10:27 AM
Similar stack trace doesn’t mean this is the same issue. It generally means that “something wrong happened during GC”. At this stage, it is mostly impossible to say if the problem is even caused by Kotlin. To investigate the problem, we need more details, starting with crash reports and the corresponding application bundle. Were you able to reproduce the problem locally?
Has this issue fixed by
1.7.21
or greater?
The known issue is fixed in 1.7.20.
231 Views