[Android] parallel setItem calls crash app

[ShaMan123]

Current behavior

• parallel calls to setItem with a large data object cause app to crash with no visible error, resulting in corrupted memory and loss of data.
• After disabling the concurrent calls a proper error surfaced saying that the database/system is out of memory.
• Seems it's not accurate because after splitting the data into several database items the problem was gone, never to return.
• I guess this can be avoided with a best practice doc but...

Expected behavior

should surface proper errors such as max size exceeded, concurrent write exception etc.

Repro steps

1. use setItem to set a large amount of data on a single item.
2. create a race condition: call setItem from different places at the same time.
3. From adb path run adb logcat -v time
4. you should see a stack trace with tag libc after app crashes:
5. disable concurrent calls
6. setItem should throw an error with code 13 - database out of memory

Environment

     "@react-native-community/async-storage": "^1.5.0",
    "react-native": "0.59.8",

Stack Trace

06-16 21:42:36.720 F/libc    (28996): Fatal signal 4 (SIGILL), code 1, fault addr 0xa0cff6b0 in tid 29144 (mqt_js)
06-16 21:42:36.830 F/DEBUG   (  399): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
06-16 21:42:36.830 F/DEBUG   (  399): Build fingerprint: 'samsung/j5xnltexx/j5xnlte:6.0.1/MMB29M/J510FNXXU2APL4:user/release-keys'
06-16 21:42:36.830 F/DEBUG   (  399): Revision: '4'
06-16 21:42:36.830 F/DEBUG   (  399): ABI: 'arm'
06-16 21:42:36.830 F/DEBUG   (  399): pid: 28996, tid: 29144, name: mqt_js  >>> com.rnmathexample <<<
06-16 21:42:36.830 F/DEBUG   (  399): signal 4 (SIGILL), code 1 (ILL_ILLOPC), fault addr 0xa0cff6b0
06-16 21:42:36.860 F/DEBUG   (  399):     r0 bbadbeef  r1 00000000  r2 00000003  r3 00000000
06-16 21:42:36.860 F/DEBUG   (  399):     r4 02000010  r5 9d9e8b8c  r6 a0e9fd04  r7 00000090
06-16 21:42:36.860 F/DEBUG   (  399):     r8 02000010  r9 9f579de8  sl 9f579bb0  fp 9f579e40
06-16 21:42:36.860 F/DEBUG   (  399):     ip b6cff620  sp 9f579ac0  lr b6cbce37  pc a0cff6b0  cpsr 600d0030
06-16 21:42:36.880 F/DEBUG   (  399):
06-16 21:42:36.880 F/DEBUG   (  399): backtrace:
06-16 21:42:36.880 F/DEBUG   (  399):     #00 pc 005e76b0  /data/app/com.rnmathexample-2/lib/arm/libjsc.so (_ZN7bmalloc4Heap13allocateLargeERNSt6__ndk111unique_lockINS_5MutexEEEjj+23)
06-16 21:42:36.880 F/DEBUG   (  399):     #01 pc 005e47cb  /data/app/com.rnmathexample-2/lib/arm/libjsc.so (_ZN7bmalloc9Allocator13allocateLargeEj+102)
06-16 21:42:36.880 F/DEBUG   (  399):     #02 pc 005e4613  /data/app/com.rnmathexample-2/lib/arm/libjsc.so (_ZN7bmalloc9Allocator10reallocateEPvj+338)
06-16 21:42:36.880 F/DEBUG   (  399):     #03 pc 00577feb  /data/app/com.rnmathexample-2/lib/arm/libjsc.so (_ZN3WTF11fastReallocEPvj+38)
06-16 21:42:36.880 F/DEBUG   (  399):     #04 pc 00584e61  /data/app/com.rnmathexample-2/lib/arm/libjsc.so (_ZN3WTF10StringImpl10reallocateEONS_3RefIS0_NS_13DumbPtrTraitsIS0_EEEEjRPh+36)
06-16 21:42:36.880 F/DEBUG   (  399):     #05 pc 005843c5  /data/app/com.rnmathexample-2/lib/arm/libjsc.so (_ZN3WTF13StringBuilder16reallocateBufferIhEEvj+50)
06-16 21:42:36.880 F/DEBUG   (  399):     #06 pc 00584a9f  /data/app/com.rnmathexample-2/lib/arm/libjsc.so (_ZN3WTF13StringBuilder22appendQuotedJSONStringERKNS_6StringE+130)
06-16 21:42:36.880 F/DEBUG   (  399):     #07 pc 00462187  /data/app/com.rnmathexample-2/lib/arm/libjsc.so (_ZN3JSC11Stringifier22appendStringifiedValueERN3WTF13StringBuilderENS_7JSValueERKNS0_6HolderERKNS_27PropertyNameForFunctionCallE+2622)
06-16 21:42:36.880 F/DEBUG   (  399):     #08 pc 00463165  /data/app/com.rnmathexample-2/lib/arm/libjsc.so (_ZN3JSC11Stringifier6Holder18appendNextPropertyERS0_RN3WTF13StringBuilderE+2816)
06-16 21:42:36.880 F/DEBUG   (  399):     #09 pc 00462379  /data/app/com.rnmathexample-2/lib/arm/libjsc.so (_ZN3JSC11Stringifier22appendStringifiedValueERN3WTF13StringBuilderENS_7JSValueERKNS0_6HolderERKNS_27PropertyNameForFunctionCallE+3120)
06-16 21:42:36.880 F/DEBUG   (  399):     #10 pc 004615bb  /data/app/com.rnmathexample-2/lib/arm/libjsc.so (_ZN3JSC11Stringifier9stringifyENS_7JSValueE+208)
06-16 21:42:36.880 F/DEBUG   (  399):     #11 pc 004660c5  /data/app/com.rnmathexample-2/lib/arm/libjsc.so (_ZN3JSC22JSONProtoFuncStringifyEPNS_9ExecStateE+176)
06-16 21:42:36.880 F/DEBUG   (  399):     #12 pc 00005f87  <unknown>

[krizzu]

Hi @ShaMan123 ,

Like RN docs says, It is recommended that you use an abstraction on top of AsyncStorage instead of AsyncStorage directly for anything more than light usage since it operates globally.

So in other words, the best practice here is to create an abstraction over Async Storage. You can create a queue-like implementation, where you can make sure that your calls are processed "synchronously".

Regarding error message:

After disabling the concurrent calls a proper error surfaced saying that the database/system is out of memory.

So it seems like you're getting that error? We had out of memory question in the past, here's the comment explaining it.

We're more than happy to see a possible solution to this error.

thanks.

[ShaMan123]

closing