Status Update
Comments
jp...@google.com <jp...@google.com>
jo...@google.com <jo...@google.com> #2
There are a few more changes to DataStoreImpl's logic which makes a reevaluation necessary.
Now with Yigit's changes, datastore's
A ReadException is not automatically handled and stays in cache until a updateData call which revisits handleUpdate
call proceeds to
jo...@google.com <jo...@google.com> #3
can we create a test failure for this? I'm not fully sure what is going wrong here, it is a bit hard to track w/o a repro case.
jo...@google.com <jo...@google.com> #4
can we create a test failure for this?
Sure I'm working on the code changes.
In the meantime I think this bug might makes the errors e.g. in
ap...@google.com <ap...@google.com> #5
Branch: androidx-main
commit 383a67d0e5a9b35e394b212db35bdee892b167fb
Author: Zhiyuan Wang <zhiyuanwang@google.com>
Date: Wed Feb 21 17:04:40 2024
Add tests to verify that CorruptionException is not properly handled after DataStore's first disk read. If the internal state is [ReadException], it will not recover for the rest of the lifecycle.
Fix in the follow up change.
Bug: 289582516
Test: ./gradlew :datastore:datastore-core:jvmTest
Change-Id: Ie77900b5c2cb8fb8e55d4c40364491dea9250784
M datastore/datastore-core/src/commonTest/kotlin/androidx/datastore/core/SingleProcessDataStoreTest.kt
jo...@google.com <jo...@google.com>
an...@google.com <an...@google.com> #6
Branch: androidx-main
commit 70085fee2af278bb8c3e45e1acfcf3f4cbb05c5a
Author: Zhiyuan Wang <zhiyuanwang@google.com>
Date: Thu Feb 22 15:08:34 2024
DataStore handles CorruptionException for all reads and writes.
Before this change, DataStore didn't handle the CorruptionException for both the reads and writes after initialization.
Fixes: 289582516
Test: ./gradlew :datastore:datastore-core:jvmTest
Change-Id: Icb07b140017b62a905d3626f82aeb993f636c053
M datastore/datastore-core/src/commonMain/kotlin/androidx/datastore/core/DataStoreImpl.kt
M datastore/datastore-core/src/commonTest/kotlin/androidx/datastore/core/SingleProcessDataStoreTest.kt
an...@google.com <an...@google.com> #7
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.datastore:datastore-core:1.1.0-beta02
androidx.datastore:datastore-core-android:1.1.0-beta02
androidx.datastore:datastore-core-iosarm64:1.1.0-beta02
androidx.datastore:datastore-core-iossimulatorarm64:1.1.0-beta02
androidx.datastore:datastore-core-iosx64:1.1.0-beta02
androidx.datastore:datastore-core-jvm:1.1.0-beta02
androidx.datastore:datastore-core-linuxx64:1.1.0-beta02
androidx.datastore:datastore-core-macosarm64:1.1.0-beta02
androidx.datastore:datastore-core-macosx64:1.1.0-beta02
de...@google.com <de...@google.com> #8
Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:
- Android Emulator 33.1.4
We encourage you to try the latest update.
If you notice further issues or have questions, please file a new bug report.
Thank you for taking the time to submit feedback — we really appreciate it!
se...@gmail.com <se...@gmail.com> #9
Android 14
Description
We do not (yet) have a way to reproduce the problem, but we can see on go/crash an high level of report with `EXC_BAD_ACCESS` issue with
`std::__1::basic_ostream<char, std::__1::char_traits<char>>::sentry::~sentry()`
The stack doesn't see much, except that this is on M1 ( qemu-arch-aarch64, using Qt6)
```
Stack Quality26%Show frame trust levels
0x00000001aba1d40c (libc++.1.dylib + 0x0001f40c) std::__1::basic_ostream<char, std::__1::char_traits<char>>::sentry::~sentry()
0x000000010103d768 (qemu-system-aarch64 + 0x001b1768)
0x000000010103d768 (qemu-system-aarch64 + 0x001b1768)
0x0000000101447224 (qemu-system-aarch64 + 0x005bb224)
0x000000010143c138 (qemu-system-aarch64 + 0x005b0138)
0x00000001069ccc48 (libQt6CoreAndroidEmu.6.2.1.dylib + 0x00010c48)
0x00000001069ccb10 (libQt6CoreAndroidEmu.6.2.1.dylib + 0x00010b10)
0x00000001069d319c (libQt6CoreAndroidEmu.6.2.1.dylib + 0x0001719c)
0x0000000107c2ea90 (libQt6GuiAndroidEmu.6.2.1.dylib + 0x0008aa90)
0x0000000107c75c8c (libQt6GuiAndroidEmu.6.2.1.dylib + 0x000d1c8c)
0x00000001066c8a4c (libqcocoaAndroidEmu.dylib + 0x00014a4c)
0x00000001abb9da04 (CoreFoundation + 0x00081a04) __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
0x00000001abb9d998 (CoreFoundation + 0x00081998) __CFRunLoopDoSource0
0x00000001abb9d708 (CoreFoundation + 0x00081708) __CFRunLoopDoSources0
0x00000001abb9c30c (CoreFoundation + 0x0008030c) __CFRunLoopRun
0x00000001abb9b874 (CoreFoundation + 0x0007f874) CFRunLoopRunSpecific
0x00000001b527bf9c (HIToolbox + 0x00031f9c) RunCurrentEventLoopInMode
0x00000001b527bc2c (HIToolbox + 0x00031c2c) ReceiveNextEventCommon
0x00000001b527bb28 (HIToolbox + 0x00031b28) _BlockUntilNextEventMatchingListInModeWithFilter
0x00000001aee21848 (AppKit + 0x00039848) _DPSNextEvent
0x00000001aee209d8 (AppKit + 0x000389d8) -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]
0x00000001aee14e08 (AppKit + 0x0002ce08) -[NSApplication run]
0x00000001066c792c (libqcocoaAndroidEmu.dylib + 0x0001392c)
0x0000000106a547f0 (libQt6CoreAndroidEmu.6.2.1.dylib + 0x000987f0)
0x0000000106a4bb44 (libQt6CoreAndroidEmu.6.2.1.dylib + 0x0008fb44)
0x000000010143a3f8 (qemu-system-aarch64 + 0x005ae3f8)
0x000000010103caf0 (qemu-system-aarch64 + 0x001b0af0)
0x00000001ab793e4c (dyld + 0x00005e4c) start
```
This is seen with stable 32.1.12 , after 1 week we have 2035 sample reports from 745 unique users