We’re running into a strange issue in release iOS builds with the new memory model. Doesn’t happen i...
a

ankushg

over 3 years ago
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:
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?
Hey all, small announcement :mega: : with the Jetpack Compose 1.8. beta01 release, you may notice th...
s

Simona Stojanovic

10 months ago
Hey all, small announcement 📣 : with the Jetpack Compose 1.8. beta01 release, you may notice that a significant number of APIs that were previously experimental, have been graduated to stable. 🫶 We care a lot about providing a high quality and cohesive API surface for Compose, while also adhering to strict binary compatibility across releases, to ensure upgrades are relatively straightforward. We’ve heard from the community that APIs that have been experimental for longer are harming the Compose experience, which is why we are decreasing our usage of experimental APIs moving forward. In 1.8, we will stabilize all experimental APIs in the Foundation and UI modules that have been unchanged for more than one full release cycle, and we plan to do the same for more modules in the future. As part of this effort, we have also identified APIs added in recent releases that are not what we believe we should commit to long term. This has led to the decision to deprecate the experimental
ContextualFlowRow
and
ContextualFlowColumn
, added in 1.7. It is possible for developers to implement their particular use cases, while we work on a plan for future components that can cover these functionalities better. The related APIs
FlowRow
and
FlowColumn
will become stable, however without the new
overflow
parameter
added in the last release. Please reach out to us if you have any questions or concerns, thanks! gratitude thank you
👍 12
❤️ 13
👍🏻 0
🔥 7
thank you color 5
👍🏾 2