Low Memory 1GB device and Realm Crashes

[Qubitium]

We are getting lots of invalid argument bad file format crashes on various low memory devices on Android 4.x. The only thing they have in common is all the devices have only 1gb of installed ram. Device range from 2013 models to early 2015 models and cpus include both mediatek and Qualcomm.

Realm encryption is enabled and we suspect that may be the culprit, for now.

We are in the process of purchasing a crashing device to track the source but want to see if the realm team has seen these type of strange crashes.

[beeender]

Can you please share some crash log with us if you have now? Thanks!

[Qubitium]

Update:

1. We have one of the crashing devices, not the same user device, but one of same model and make though different region (Samsung Grand Prime). Unfortunately we are unable to recreate the crashes.

2. Our latest update disabled encryption in Realm for the problem db in question which is just a k/v String key (primary), String data absolutely dead simple db. After the update release, we have yet to receive 1 single crash report.

Conclusion: We still no idea how to reproduce the crash but it is happening and disabling encryption removed the crashes on 1GB devices such as as the Samsung Grand Prime.

@beeender We only have crashanalytic crash stack traces which doesn't point to anything in particular except for the exception at createInstance with a realmConfig that has encryption enabled for the k/v db.

[beeender]

@diegomontoya It seems the crash is in the native code. Any chance you can get the tombstone log or any kind of native crash log for us?

[beeender]

@diegomontoya How is this going on? Do you have more information about this? Like any signal triggered the native crash etc.

[Qubitium]

@beender The best I can do is google's ANR report which doesn't have full debug symbol stack traces. We are unable to reproduce the bug with our 1GB device. The following in a ANR which same crashpoint on many 1GB devices.

---

Build fingerprint: 'Lenovo/scofield_row/S850:4.4.2/KOT49H/S850_ROW_S217_150420.:user/release-keys'
pid: 6230, tid: 6230, name: ress.app >>> com.app <<<
signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 60736000
r0 6128c5e8 r1 60735fe8 r2 0078d5d0 r3 42899f50
r4 00000000 r5 00000000 r6 00000000 r7 00000000
r8 00000000 r9 6050b120 sl 61141aa8 fp 6050b098
ip 00000000 sp beea3bb8 lr 42899f18 pc 4012a490 cpsr 200d0010

backtrace:
#00 pc 00026490 /system/lib/libc.so (__memcpy_base_aligned+68)
#1 pc 0003f93b /data/app-lib/com.app-1/librealm-jni.so

code around pc:
4012a470 e2422004 e2522020 f5d1f100 f590f100
4012a480 e8b151f8 e2522020 e8a051f8 ba000003
4012a490 e8b151f8 e2522020 e8a051f8 aafffff5
4012a4a0 e2822020 e3120010 0a000005 e1c140d0
4012a4b0 e1c040f0 e1c140d8 e1c040f8 e2811010
4012a4c0 e2800010 e1b0ce82 3a000001 e0c140d8
4012a4d0 e0c040f8 aa000001 e4914004 e4804004
4012a4e0 e1b02f82 14d1e001 14c0e001 24d1c001
4012a4f0 25d1e000 24c0c001 25c0e000 e0cd80d8
4012a500 e0cd60d8 e0cd40d8 e8bd8001 e26cc004
4012a510 e35c0002 c4d1e001 c4c0e001 a4d1e001
4012a520 a4c0e001 e4d1e001 e4c0e001 e042200c
4012a530 eaffffca e52de004 e59f000c e59f1004
4012a540 e080000f faffc1e5 000138e4 0003bb38
4012a550 e1520003 9a000008 e52de004 e59f000c
4012a560 e59f1004 e080000f faffc1dc 000138fd

code around lr:
42899ef8 00000000 0000001b 41c23430 00000000
42899f08 00000000 42899728 00000000 0000003b
42899f18 41c1c4f8 00000000 00000000 00000000
42899f28 00000000 00000000 42899f50 00000000
42899f38 428999b8 00000000 00000001 00000000
42899f48 00000000 0000005b 419f8338 00000000
42899f58 4277ee48 4289a098 41a06c98 00000000
42899f68 42899f18 00000000 4289a018 4289a2d0
42899f78 42899ff8 42899ab8 000001e1 00000000
42899f88 00000000 00000000 00000005 00000003
42899f98 00000001 00000000 00000000 0000001b
42899fa8 41a143e0 00000000 42899fc0 00000001
42899fb8 0000000f 0000003b 419f8950 00000000
42899fc8 00000010 00000000 006f0070 006c006f
42899fd8 0033002d 0074002d 00720068 00610065
42899fe8 002d0064 00000031 00000000 00000023

[Qubitium]

Another ANR with multiple crashes on 1GB devices. Very similar to the above one and crashing at memcpy. Could be related to memory allocation/usage on low mem devices.

---

Build fingerprint: 'lge/b2ldsn_global_com/b2ldsn:4.4.2/KOT49I/1432216233:user/release-keys'
pid: 1949, tid: 1949, name: ress.app >>> com.app <<<
signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 619c5000
r0 623b2588 r1 619c4ff0 r2 00570830 r3 00000000
r4 00000000 r5 00000000 r6 00000000 r7 00000000
r8 00000000 r9 00000002 sl 619043e0 fp 617de610
ip 00000000 sp becddb08 lr 00000000 pc 40069178 cpsr 200d0010

backtrace:
#00 pc 00025178 /system/lib/libc.so (__memcpy_base_aligned+52)
#1 pc 0003f93b /data/app-lib/com.app-1/librealm-jni.so

code around pc:
40069158 e2103004 0a000002 e4913004 e4803004
40069168 e2422004 e2522020 f5d1f100 f590f100
40069178 e8b151f8 e2522020 e8a051f8 ba000003
40069188 e8b151f8 e2522020 e8a051f8 aafffff5
40069198 e2822020 e3120010 0a000005 e1c140d0
400691a8 e1c040f0 e1c140d8 e1c040f8 e2811010
400691b8 e2800010 e1b0ce82 3a000001 e0c140d8
400691c8 e0c040f8 aa000001 e4914004 e4804004
400691d8 e1b02f82 14d1e001 14c0e001 24d1c001
400691e8 25d1e000 24c0c001 25c0e000 e0cd80d8
400691f8 e0cd60d8 e0cd40d8 e8bd8001 e26cc004
40069208 e35c0002 c4d1e001 c4c0e001 a4d1e001
40069218 a4c0e001 e4d1e001 e4c0e001 e042200c
40069228 eaffffca e52de004 e59f000c e59f1004
40069238 e080000f faffc1d1 000138e4 00039e40
40069248 e320f000 e320f000 e1520003 9a000008

code around lr:
00000000 ffffffff ffffffff ffffffff ffffffff
00000010 ffffffff ffffffff ffffffff ffffffff
00000020 ffffffff ffffffff ffffffff ffffffff
00000030 ffffffff ffffffff ffffffff ffffffff
00000040 ffffffff ffffffff ffffffff ffffffff
00000050 ffffffff ffffffff ffffffff ffffffff
00000060 ffffffff ffffffff ffffffff ffffffff
00000070 ffffffff ffffffff ffffffff ffffffff
00000080 ffffffff ffffffff ffffffff ffffffff
00000090 ffffffff ffffffff ffffffff ffffffff
000000a0 ffffffff ffffffff ffffffff ffffffff
000000b0 ffffffff ffffffff ffffffff ffffffff
000000c0 ffffffff ffffffff ffffffff ffffffff
000000d0 ffffffff ffffffff ffffffff ffffffff
000000e0 ffffffff ffffffff ffffffff ffffffff
000000f0 ffffffff ffffffff ffffffff ffffffff

[Qubitium]

Another variation of memory copy crashing librealm on 1GB devices: multiple device crash just like the previous posts. If memory is allocated correctly for copy dest and copy source exists I don't see how this can crash.

---

Build fingerprint: 'TCL/SOUL4NA_METROPCS/SOUL4NA:4.4.2/KOT49H/vC2V-0:user/release-keys'
pid: 3279, tid: 3279, name: ress.app >>> com.app<<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 60dfeffc
r0 00000000 r1 60dff008 r2 64bafa68 r3 00000000
r4 60dff000 r5 616695e0 r6 642a4a68 r7 64b0f048
r8 00f44010 r9 60155870 sl 6058bb08 fp 601557e8
ip 0021a976 sp beb84c18 lr 4007bb0c pc 400a4190 cpsr 200d0010

backtrace:
#00 pc 00050190 /system/lib/libc.so (bcopy+240)
#1 pc 00027b08 /system/lib/libc.so (memmove+68)
#2 pc 0003f93b /data/app-lib/com.app-1/librealm-jni.so

code around pc:
400a4170 e2644000 e0877004 e0866004 e3580000
400a4180 0a00000a e1a05007 e1a04006 e1a0c008
400a4190 e5343004 e25cc001 e5253004 1afffffb
400a41a0 e0688f08 e1a08108 e0866008 e0877008
400a41b0 e3500000 08bd81f0 e1a02006 e1a01007
400a41c0 e0603006 e5720001 e1520003 e5610001
400a41d0 1afffffb e8bd81f0 e0210004 e3100003
400a41e0 1a00003f e2046003 e2665004 e0653002
400a41f0 e081c005 e2442001 e5f20001 e4c10001
400a4200 e151000c 1afffffb e0844005 e1b06123
400a4210 0a00000b e284c004 e2810004 e1a02006
400a4220 e51c5004 e2522001 e5005004 e28cc004
400a4230 e2800004 1afffff9 e1a06106 e0844006
400a4240 e0811006 e2133003 08bd81f0 e2444001
400a4250 e081c003 e5f42001 e4c12001 e151000c
400a4260 1afffffb e8bd81f0 e3530b01 3a000020

code around lr:
4007baec e1510004 2a000002 e0610004 e1520000
4007bafc 9afffff7 e1a00001 e1a01004 eb00a164
4007bb0c e1a00004 e8bd8010 e92d4038 e59f0038
4007bb1c e59f5038 e08f0000 e08f5005 ebff9f20
4007bb2c e5954004 e1540005 08bd8038 e5943008
4007bb3c e3530000 0a000000 e12fff33 e5944004
4007bb4c e1540005 1afffff8 e8bd8038 0003a5b4
4007bb5c 0003a5b4 e92d4030 e59f5058 e24dd00c
4007bb6c e08f5005 e5954000 e1540005 0a000006
4007bb7c e594300c e3530000 0a000000 e12fff33
4007bb8c e5944000 e1540005 1afffff8 e28d0004
4007bb9c ebff9e37 e28d0004 e3a01001 ebff9e4a
4007bbac e59f0014 e28d1004 e08f0000 ebff9e73
4007bbbc e28dd00c e8bd8030 0003a56c 0003a520
4007bbcc e92d4038 e59f5038 e08f5005 e5954000
4007bbdc e1540005 0a000006 e5943010 e3530000

[beeender]

@diegomontoya I have some 1GB devices, do you mind send the apk to me for testing?

[beeender]

@diegomontoya the 0.82.2 has been released which fixed 3 problems related with encryption

• Fixed a potential stack overflow issue which might cause a crash when encryption was used.
• Embedded crypto functions into Realm dynamic lib to avoid random issues on some devices.
• Throw RealmEncryptionNotSupportedException if the device doesn't support Realm encryption. At least one device type (HTX One X) contains system bugs that prevents Realm's encryption from functioning properly. This is now detected, and an exception is thrown when trying to open/create an encrypted Realm file. It's up to the application to catch this and decide if it's OK to proceed without encryption instead.

Those three all would generate some really strange back trace. If you don't mind, please update the realm to 0.82.2 to see if the issue gets fixed. Thanks!

[kneth]

I'm closing the issue since we released a fix. @diegomontoya if the problem still persist, please open a new issue.