Crashed: Thread, SIGABRT 0x0000000000000000
See original GitHub issueHow frequently does the bug occur?
Sometimes
Description
We recently updated from realm 3.6.4 to 10.2.0 ((ir)relevant issue: https://github.com/realm/realm-js/issues/3587).
(That was a necessary update, as otherwise iOS 15 was crashing)
So, on iOS there is no problem with the update on the data or on the update of the realm file.
Though, on android, we have 6 clients the last 5 days, having the same error. We have received the errors in crashlytics, and we have no more clues than what it gives us atm.
Seems like most of the times the error is happening in our splash screen, where the realm is being initiated and the first queries/writes are happening, but that’s not always the case as we have seen this happening on next screens too.
Every user affected is on android 11, and the current list of affected devices is: Galaxy Tab S5e, Galaxy S10, Galaxy Tab S7 and Galaxy Tab A7.
Also, some of these users have reported this error again and again after some seconds, so it seems like they are not able to recover/proceed, but that’s a personal guess.
Stacktrace & log output
Crashed: Thread : SIGABRT 0x0000000000000000
#00 pc 0x8cea4 libc.so
#01 pc 0x8ce74 libc.so
#02 pc 0x4207ec librealm.so
#03 pc 0x1e8f38 librealm.so
#04 pc 0x78e85e9b3c
#05 pc 0x78e87fed70
#06 pc 0x78d4b1c98c
#07 pc 0x78d4ad4dd8
#08 pc 0x78d4b1c964
#09 pc 0x78d4ad96f8
#10 pc 0x78e87fed70
#11 pc 0x78d4ad395c
#12 pc 0x78d4acbb04
#13 pc 0x78d4b1d0c4
#14 pc 0x78d4ac37d8
#15 pc 0x78e87fecd0
#16 pc 0x78e87fecd0
#17 pc 0x78e87fecd0
#18 pc 0x78d4b1cecc
#19 pc 0x78e87fecd0
#20 pc 0x78d499c398
#21 pc 0x78e87ea6f4
#22 pc 0x78e873b778
#23 pc 0x78e873b7d0
#24 pc 0x21128 libjscexecutor.so
#25 pc 0x20f60 libjscexecutor.so
#26 pc 0xa1370 libreactnativejni.so
#27 pc 0xa2350 libreactnativejni.so
#28 pc 0x68d48 libreactnativejni.so
#29 pc 0x59a70 libreactnativejni.so
#30 pc 0x599ec libreactnativejni.so
#31 pc 0x6bfc5c boot-framework.oat
#32 pc 0x78f1fe9c34
#33 pc 0x6c31bc boot-framework.oat
#34 pc 0x666ffc libart.so
#35 pc 0x78f1fe9e28
#36 pc 0x15ced8 boot.oat
#37 pc 0x134564 libart.so
#38 pc 0x198e94 libart.so
#39 pc 0x666ffc libart.so
#40 pc 0x5320fc libart.so
#41 pc 0x4df58 libc.so
#42 pc 0x583310 libart.so
#43 pc 0x521a0 libc.so
#44 pc 0x5332fc libart.so
#45 pc 0x666ffc libart.so
#46 pc 0x58081c libart.so
#47 pc 0x667ffc libart.so
#48 pc 0x9138d libart.so
#49 pc 0xf41b4 libc.so
#50 pc 0xf4170 libc.so
#51 pc 0x8ede4 libc.so
#52 pc 0x580320 libart.so
Can you reproduce the bug?
Not yet
Reproduction Steps
Not yet any reproduction, we’ll keep trying with focus on android 11 emulators - devices
Version
“realm”: “^10.2.0”
What SDK flavour are you using?
Local Database only
Are you using encryption?
No, not using encryption
Platform OS and version(s)
Android 11
Build environment
- Build using node10
- RN: 0.63.4
Issue Analytics
- State:
- Created 2 years ago
- Reactions:1
- Comments:12 (5 by maintainers)
Top Related StackOverflow Question
Hey, the active realm file is saved into private storage, in internal documents, on the default path that the realm is initiated when a path is not specified. The backups of our active realm file are saved in ExternalStorageDirectoryPath/AppName/Backups/ using the
writeCopyTomethod. Copying the file using thecopyFilemethod ofrn-fsresolved this as a workaround till this gets resolved.Hey @kraenhansen We have some good news! We managed to reproduce, and we have all the traces needed locally. It’s happening during a (automatic) backup creation on the startup of the app, which we do using the
writeCopyTomethod. I’ll update with more info in a while. Seems like that the backup is well created, despite the crash, and the users can proceed to the app when they reopen. They reface the issue when the next automatic backup is gonna be needed according to our policy.