Encryption still crashes on ARM devices #2537

beeender · 2017-03-21T15:42:34Z

There is a testing project in the java issue which can easily reproduce the crash. It is using realm-java 3.0.0/realm-core 2.3.2 .

From our testing:

no crashes has been see on emulator (x86)
takes 10 minutes on @kneth 's OPO (armeabi-v7a)
takes 3 seconds to crash on my Huawei Honor 7 and Xiaomi Mi5 (both arm64-v8a)

The original crash log shows some string corruption, but since it would only crash if the string conversion fails but not other value types, so it might not only happen to string_array.

By disable asm for openssl with no-asm and enable core assertions, it crashes with:

03-21 23:31:25.315 18766-19119/io.binarysolutions.realmmemtest E/REALM: ../realm/array_string.hpp:145: [realm-core-2.3.2] Assertion failed: data[array_size] == 0 with (data[array_size], array_size) =  [35, 18446744073709551538]
                                                                        IMPORTANT: if you see this error, please send this log to help@realm.io.
03-21 23:31:25.318 18766-19119/io.binarysolutions.realmmemtest A/libc: Fatal signal 6 (SIGABRT), code -6 in tid 19119 (Thread-5)
                                                                       
                                                                       [ 03-21 23:31:25.322   458:  458 W/         ]
                                                                       debuggerd: handling request: pid=18766 uid=10066 gid=10066 tid=19119
03-21 23:31:25.510 19160-19160/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
03-21 23:31:25.510 19160-19160/? A/DEBUG: Build fingerprint: 'Xiaomi/gemini/gemini:7.0/NRD90M/V8.2.1.0.NAACNEB:user/release-keys'
03-21 23:31:25.510 19160-19160/? A/DEBUG: Revision: '0'
03-21 23:31:25.510 19160-19160/? A/DEBUG: ABI: 'arm64'
03-21 23:31:25.511 19160-19160/? A/DEBUG: pid: 18766, tid: 19119, name: Thread-5  >>> io.binarysolutions.realmmemtest <<<
03-21 23:31:25.511 19160-19160/? A/DEBUG: signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
03-21 23:31:25.511 19160-19160/? A/DEBUG:     x0   0000000000000000  x1   0000000000004aaf  x2   0000000000000006  x3   0000000000000008
03-21 23:31:25.511 19160-19160/? A/DEBUG:     x4   000000000000016d  x5   0000000000000000  x6   0000007f8ab54000  x7   0000000000000000
03-21 23:31:25.511 19160-19160/? A/DEBUG:     x8   0000000000000083  x9   ffffffffffffffdf  x10  0000000000000000  x11  0000000000000001
03-21 23:31:25.511 19160-19160/? A/DEBUG:     x12  ffffffffffffffff  x13  0000000000000000  x14  0000000000000000  x15  0012cff458ea48fd
03-21 23:31:25.512 19160-19160/? A/DEBUG:     x16  0000007f881deed0  x17  0000007f88188638  x18  00000000000000bb  x19  0000007f65ef14f8
03-21 23:31:25.512 19160-19160/? A/DEBUG:     x20  0000000000000006  x21  0000007f65ef1450  x22  0000000000000011  x23  00000000130d3970
03-21 23:31:25.512 19160-19160/? A/DEBUG:     x24  0000000013062880  x25  00000000130cf980  x26  0000000000000000  x27  00000000130c6c00
03-21 23:31:25.512 19160-19160/? A/DEBUG:     x28  0000000012ce8800  x29  0000007f65eefc30  x30  0000007f88185ac8
03-21 23:31:25.512 19160-19160/? A/DEBUG:     sp   0000007f65eefc10  pc   0000007f88188640  pstate 0000000060000000
03-21 23:31:25.539 19160-19160/? A/DEBUG: backtrace:
03-21 23:31:25.539 19160-19160/? A/DEBUG:     #00 pc 000000000006b640  /system/lib64/libc.so (tgkill+8)
03-21 23:31:25.540 19160-19160/? A/DEBUG:     #01 pc 0000000000068ac4  /system/lib64/libc.so (pthread_kill+64)
03-21 23:31:25.540 19160-19160/? A/DEBUG:     #02 pc 0000000000024010  /system/lib64/libc.so (raise+24)
03-21 23:31:25.540 19160-19160/? A/DEBUG:     #03 pc 000000000001ca94  /system/lib64/libc.so (abort+52)
03-21 23:31:25.540 19160-19160/? A/DEBUG:     #04 pc 00000000001ec990  /data/app/io.binarysolutions.realmmemtest-2/lib/arm64/librealm-jni.so
03-21 23:31:25.540 19160-19160/? A/DEBUG:     #05 pc 00000000001ec9e4  /data/app/io.binarysolutions.realmmemtest-2/lib/arm64/librealm-jni.so
03-21 23:31:25.540 19160-19160/? A/DEBUG:     #06 pc 00000000001ecb2c  /data/app/io.binarysolutions.realmmemtest-2/lib/arm64/librealm-jni.so
03-21 23:31:25.540 19160-19160/? A/DEBUG:     #07 pc 0000000000173d3c  /data/app/io.binarysolutions.realmmemtest-2/lib/arm64/librealm-jni.so
03-21 23:31:25.540 19160-19160/? A/DEBUG:     #08 pc 0000000000188ca8  /data/app/io.binarysolutions.realmmemtest-2/lib/arm64/librealm-jni.so
03-21 23:31:25.540 19160-19160/? A/DEBUG:     #09 pc 0000000000058578  /data/app/io.binarysolutions.realmmemtest-2/lib/arm64/librealm-jni.so (Java_io_realm_internal_Table_nativeGetName+256)
03-21 23:31:25.540 19160-19160/? A/DEBUG:     #10 pc 00000000005e8f88  /data/app/io.binarysolutions.realmmemtest-2/oat/arm64/base.odex (offset 0x576000)

parsed stack:

Stack frame #00 pc 000000000006b640  /system/lib64/libc.so (tgkill+8)
Stack frame #01 pc 0000000000068ac4  /system/lib64/libc.so (pthread_kill+64)
Stack frame #02 pc 0000000000024010  /system/lib64/libc.so (raise+24)
Stack frame #03 pc 000000000001ca94  /system/lib64/libc.so (abort+52)
Stack frame #04 pc 00000000001ec990  /data/app/io.binarysolutions.realmmemtest-2/lib/arm64/librealm-jni.so: Routine please_report_this_error_to_help_at_realm_dot_io at :?
Stack frame #05 pc 00000000001ec9e4  /data/app/io.binarysolutions.realmmemtest-2/lib/arm64/librealm-jni.so: Routine realm::util::terminate_internal(std::basic_stringstream<char, std::char_traits<char>, std::allocator<char> >&) at terminate.cpp:?
Stack frame #06 pc 00000000001ecb2c  /data/app/io.binarysolutions.realmmemtest-2/lib/arm64/librealm-jni.so: Routine realm::util::terminate_with_info(char const*, char const*, long, char const*, std::initializer_list<realm::util::Printable>&&) at :?
Stack frame #07 pc 0000000000173d3c  /data/app/io.binarysolutions.realmmemtest-2/lib/arm64/librealm-jni.so: Routine realm::ArrayString::get(unsigned long) const at :?
Stack frame #08 pc 0000000000188ca8  /data/app/io.binarysolutions.realmmemtest-2/lib/arm64/librealm-jni.so: Routine realm::Group::get_child_name(unsigned long) const at :?
Stack frame #09 pc 0000000000058578  /data/app/io.binarysolutions.realmmemtest-2/lib/arm64/librealm-jni.so (Java_io_realm_internal_Table_nativeGetName+256): Routine Java_io_realm_internal_Table_nativeGetName at ??:?
Stack frame #10 pc 00000000005e8f88  /data/app/io.binarysolutions.realmmemtest-2/oat/arm64/base.odex (offset 0x576000)

The text was updated successfully, but these errors were encountered:

ironage · 2017-03-21T23:52:53Z

I see that array_size is 18446744073709551538 which is very close to the 64 bit maximum. Does it really have strings of that length or could that index an error?

beeender · 2017-03-22T08:43:12Z

no, I believe it doesn't . And same app doesn't crash without encryption.

kneth · 2017-03-22T08:50:23Z

The test app is the exact same test app which lead us to the last encryption bug fix (slightly different parameters). There are two writer threads and one read threads. The string lengths are max 13 characters, and the writer threads are continuously updating values.

kneth · 2017-03-22T08:51:43Z

@bios-seiji You might wish to follow this issue.

ironage · 2017-03-28T22:54:27Z

I have made a core level test that is modelled after the sample java application (with 2 reader threads and 2 writer threads). It only finds crashes when run on an actual android device (I am testing with a LG G5). For another data point, an example crash that I am seeing is below (spec accessor is reporting a wrong column type).

03-28 14:44:39.376 16382 16403 E REALM   : table.cpp:2814: [realm-core-2.5.1] Assertion failed: type == col_type_StringEnum
03-28 14:44:39.376 16382 16403 E REALM   : IMPORTANT: if you see this error, please send this log to help@realm.io.
03-28 14:44:39.379 16382 16403 F libc    : Fatal signal 6 (SIGABRT), code -6 in tid 16403 (.realm.coretest)
03-28 14:44:39.380   467   467 W         : debuggerd: handling request: pid=16382 uid=10285 gid=10285 tid=16403
03-28 14:44:39.446 16998 16998 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
03-28 14:44:39.447 16998 16998 F DEBUG   : Build fingerprint: 'lge/h1_rgs_ca/h1:7.0/NRD90U/1632310030db6:user/release-keys'
03-28 14:44:39.447 16998 16998 F DEBUG   : Revision: '12'
03-28 14:44:39.447 16998 16998 F DEBUG   : ABI: 'arm'
03-28 14:44:39.447 16998 16998 F DEBUG   : pid: 16382, tid: 16403, name: .realm.coretest  >>> io.realm.coretest <<<
03-28 14:44:39.447 16998 16998 F DEBUG   : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
03-28 14:44:39.447 16998 16998 F DEBUG   :     r0 00000000  r1 00004013  r2 00000006  r3 00000008
03-28 14:44:39.447 16998 16998 F DEBUG   :     r4 e2e6e978  r5 00000006  r6 e2e6e920  r7 0000010c
03-28 14:44:39.447 16998 16998 F DEBUG   :     r8 e8ffd7a8  r9 da10c428  sl cc02873c  fp e2e6e89c
03-28 14:44:39.448 16998 16998 F DEBUG   :     ip 00000011  sp e2e6cdf8  lr ebf789b7  pc ebf7b238  cpsr 200f0010
03-28 14:44:39.455 16998 16998 F DEBUG   :
03-28 14:44:39.455 16998 16998 F DEBUG   : backtrace:
03-28 14:44:39.455 16998 16998 F DEBUG   :     #00 pc 0004a238  /system/lib/libc.so (tgkill+12)
03-28 14:44:39.455 16998 16998 F DEBUG   :     #01 pc 000479b3  /system/lib/libc.so (pthread_kill+34)
03-28 14:44:39.455 16998 16998 F DEBUG   :     #02 pc 0001d87d  /system/lib/libc.so (raise+10)
03-28 14:44:39.455 16998 16998 F DEBUG   :     #03 pc 00019375  /system/lib/libc.so (__libc_android_abort+34)
03-28 14:44:39.456 16998 16998 F DEBUG   :     #04 pc 000173e8  /system/lib/libc.so (abort+4)
03-28 14:44:39.456 16998 16998 F DEBUG   :     #05 pc 00ff07f9  /data/app/io.realm.coretest-2/lib/arm/libnative-activity.so (please_report_this_error_to_help_at_realm_dot_io+4)
03-28 14:44:39.456 16998 16998 F DEBUG   :     #06 pc 00ff08f7  /data/app/io.realm.coretest-2/lib/arm/libnative-activity.so
03-28 14:44:39.456 16998 16998 F DEBUG   :     #07 pc 00ff0a2b  /data/app/io.realm.coretest-2/lib/arm/libnative-activity.so (_ZN5realm4util9terminateEPKcS2_lOSt16initializer_listINS0_9PrintableEE+142)
03-28 14:44:39.456 16998 16998 F DEBUG   :     #08 pc 012daaf7  /data/app/io.realm.coretest-2/lib/arm/libnative-activity.so (_ZNK5realm5Table3getINS_10StringDataEEET_jj+362)
03-28 14:44:39.456 16998 16998 F DEBUG   :     #09 pc 012dbd41  /data/app/io.realm.coretest-2/lib/arm/libnative-activity.so (_ZNK5realm5Table10get_stringEjj+24)

kneth · 2017-03-29T07:23:25Z

@ironage Great news that you can reproduce it. Since Realm Java doesn't have assertions enables, it is likely you will see a different error.

rrrlasse · 2017-04-03T14:57:28Z

I can now reproduce the crash in Visual Studio at #2433 - it happens in the LangBindHelper_HandoverBetweenThreads unit test, which was one of those that crashed immediately before our fix.

It now crashes too, just after a long while (1 minute or so).

rrrlasse · 2017-04-03T14:58:44Z

However I'm going on vacation, so I don't think I'll be able to fix it

Zhuinden · 2017-04-05T03:30:14Z

Hmm this causes a lot of strange crashes on Java side if Realm is encrypted though.

beeender · 2017-04-11T12:39:55Z

@KynoYang sees this crash as well.

rickbijkerk · 2017-05-04T11:04:50Z

Any update on this issue? im dealing with the same problem

kneth · 2017-05-04T11:42:43Z

@rickbijkerk We have a few minor fixes but they don't constitute a complete fix.

rickbijkerk · 2017-05-04T11:48:50Z

Thanks for the fast reply.

if i can help solving this issue dont hesitate to ask. I can 100% reproduce the issue on my phone and it works without problems on my emulator.

I can share some code, but i cant share the entire project due to legal restrictions.
Is there any work around besides not using encryption at all

l1git · 2017-05-04T15:00:15Z

yes waiting also for some progress as we are also dealing with this one. We cannot reproduce but problem kicks in "randomly"

nsmnds · 2017-05-05T12:18:13Z

I'm also experiencing this crash, is there any known workaround?

GershonLin · 2017-05-09T18:03:02Z

I have encountered this problem, there are ways to solve it？

KynoYang · 2017-05-10T02:44:26Z

any progress on this issue, please? 😢

ironage · 2017-05-10T08:22:11Z

@l1git @nielssimonides @GershonLin @KynoYang Thank you for stating your interest. Unfortunately we don't have a final fix yet, but we understand the importance of this and are actively working on it. We'll be sure to update you when we have a release for you to try!

KynoYang · 2017-05-10T10:49:40Z

Thanks you, @ironage
It's great to know you're working on it. Thanks!

celesteshire · 2017-05-11T02:25:25Z

I have also encountered the same problem, hope to solve as soon as possible

lucasleongit · 2017-05-16T14:42:44Z

Is there any update for this issue @ironage? we badly need this issue solved. Getting a lot of crashes.

EdwardvanRaak · 2017-05-16T18:06:26Z

@l1git @nielssimonides @GershonLin @KynoYang @lucasleongit
Just to be clear on something, are all of you guys using encrypted realms in combination with background threads reading/writing data? Because we solved this issue by using our own executeTransaction wrapper method with a really dirty object lock + sleep fix. This will (sort of?) enforce exclusive access to realm on multiple threads.

private static final Object lock = new Object();

public static void executeTransaction(Realm realm, Realm.Transaction transaction) {
		synchronized (lock) {
			try {
				Thread.sleep(20);
				realm.executeTransaction(transaction);
                                ...

At least the UTF-16 related crashes disappeared completely for us (we had a lot of these) and we are not seeing these nativeGetName() crashes reported by our users as well.

Now obviously it's probably better to wait for the official fix since this is just painful to look at but we were somewhat desperate to fix the problem immediately. Right now I'm too afraid to remove this "fix" to 100% confirm this actually had any effect because it might have been something else.

ironage · 2017-05-16T18:08:18Z

@lucasleongit unfortunately no update yet, we are still actively working on finding a fix. We'll be sure to let you know when we find a solution.

lucasleongit · 2017-05-17T18:41:41Z

@ironage, thanks for your potential fix - I want to try this asap. hope new java SDK is released soon.

ironage · 2017-05-17T18:51:38Z

@lucasleongit The fix passed my internal tests and I think it will work for you too. We will make a release shortly and notify you when it is ready to try out. Thanks for your patience!

lucasleongit · 2017-05-17T18:54:30Z

@ironage : Awesome, Thanks a lot!

cmelchior · 2017-05-19T13:22:08Z

@lucasleongit Realm Java 3.2.1 was released with the fix for this

@ironage I believe this issue can be closed now?

beeender added S:P1 Backlog T-Bug-Crash labels Mar 21, 2017

ironage mentioned this issue Mar 23, 2017

SIGBUS crash with encrypted Realm #2396

Closed

kneth mentioned this issue Mar 23, 2017

RealmError: Unrecoverable error. Failure when converting short string to UTF-16 realm/realm-java#2492

Closed

finnschiermer assigned ironage Mar 23, 2017

kneth mentioned this issue Mar 29, 2017

Fatal signal 11 (SIGSEGV), code 1, fault addr 0x69 in tid 6254 realm/realm-java#4381

Closed

ironage added S:In Progress and removed S:P1 Backlog labels Mar 29, 2017

rrrlasse mentioned this issue Apr 4, 2017

Windows encryption #2433

Closed

beeender mentioned this issue Apr 5, 2017

Realm 2.2.1. Fatal signal 8 (SIGFPE), code -6 (SI_TKILL), fault addr 0x6a14 realm/realm-java#4425

Closed

ironage mentioned this issue May 17, 2017

Decryption buffer #2616

Merged

ironage closed this as completed May 19, 2017

ironage removed the S:In Progress label May 19, 2017

github-actions bot locked as resolved and limited conversation to collaborators Mar 22, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Encryption still crashes on ARM devices #2537

Encryption still crashes on ARM devices #2537

beeender commented Mar 21, 2017 •

edited by finnschiermer

Loading

ironage commented Mar 21, 2017

beeender commented Mar 22, 2017

kneth commented Mar 22, 2017

kneth commented Mar 22, 2017

ironage commented Mar 28, 2017

kneth commented Mar 29, 2017

rrrlasse commented Apr 3, 2017

rrrlasse commented Apr 3, 2017

Zhuinden commented Apr 5, 2017

beeender commented Apr 11, 2017

rickbijkerk commented May 4, 2017

kneth commented May 4, 2017

rickbijkerk commented May 4, 2017 •

edited

Loading

l1git commented May 4, 2017

nsmnds commented May 5, 2017

GershonLin commented May 9, 2017

KynoYang commented May 10, 2017

ironage commented May 10, 2017

KynoYang commented May 10, 2017

celesteshire commented May 11, 2017

lucasleongit commented May 16, 2017

EdwardvanRaak commented May 16, 2017 •

edited

Loading

ironage commented May 16, 2017

lucasleongit commented May 17, 2017

ironage commented May 17, 2017

lucasleongit commented May 17, 2017

cmelchior commented May 19, 2017

Encryption still crashes on ARM devices #2537

Encryption still crashes on ARM devices #2537

Comments

beeender commented Mar 21, 2017 • edited by finnschiermer Loading

ironage commented Mar 21, 2017

beeender commented Mar 22, 2017

kneth commented Mar 22, 2017

kneth commented Mar 22, 2017

ironage commented Mar 28, 2017

kneth commented Mar 29, 2017

rrrlasse commented Apr 3, 2017

rrrlasse commented Apr 3, 2017

Zhuinden commented Apr 5, 2017

beeender commented Apr 11, 2017

rickbijkerk commented May 4, 2017

kneth commented May 4, 2017

rickbijkerk commented May 4, 2017 • edited Loading

l1git commented May 4, 2017

nsmnds commented May 5, 2017

GershonLin commented May 9, 2017

KynoYang commented May 10, 2017

ironage commented May 10, 2017

KynoYang commented May 10, 2017

celesteshire commented May 11, 2017

lucasleongit commented May 16, 2017

EdwardvanRaak commented May 16, 2017 • edited Loading

ironage commented May 16, 2017

lucasleongit commented May 17, 2017

ironage commented May 17, 2017

lucasleongit commented May 17, 2017

cmelchior commented May 19, 2017

beeender commented Mar 21, 2017 •

edited by finnschiermer

Loading

rickbijkerk commented May 4, 2017 •

edited

Loading

EdwardvanRaak commented May 16, 2017 •

edited

Loading