Handling Fatal signal 11

[cre8ivejp]

Hi,
I had the same issues as described here #1388
Let's say by updating to 0.85.0, it will fix this issue, but for other unknown reason we get a Fatal signal.
Would be nice if it could be possible to create a handler for case like this and allow us to do a backup of the current data or event to show a message to the user.
Because when it happens, the user are losing his data.

Any advices?

[beeender]

Hi @cre8ivejp

When this issue happens, the Realm db won't be corrupted, and since it is not recoverable (crash in native code with invalid pointers), we cannot supply a handler for you deal with it.

May I know why cannot you to update to later version to solve this issue? What is the fatal signal you mentioned?

[cre8ivejp]

Thank you for a quick reply.

We gonna update to the latest version and see if it solves our issue.
I just asked about the handler, because if there is a way to handle it, would be helpful.

[cre8ivejp]

Just for the record, I will leave the crash log.

---

UUID: xxxxx-xxxxx-xxxxx-xxxxx
Build fingerprint: 'docomo/SO-02E/SO-02E:4.4.2/10.5.1.B.0.68/u793rQ:user/release-keys'
Revision: '0'
pid: 30481, tid: 30481, name: com.example.app >>> com.example.app <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000004
r0 00000000 r1 31626234 r2 00000000 r3 00000000
r4 7685e390 r5 31626234 r6 00580000 r7 00000000
r8 00000000 r9 bed3d0ac sl 00626131 fp 00000000
ip 767d9af8 sp bed3c990 lr 77ba7ad9 pc 77bb1594 cpsr 600f0030
d0 3403000006008000 d1 3730316435303164
d2 0000000000303164 d3 5308000011005000
d4 5322000011007000 d5 757469776b636974
d6 6e7265746e492820 d7 206c616e6f697461
d8 0000000000000000 d9 0000000000000000
d10 0000000000000000 d11 0000000000000000
d12 0000000000000000 d13 0000000000000000
d14 0000000000000000 d15 0000000000000000
d16 0000000000000000 d17 0000000000000000
d18 0000000000000000 d19 0000000000000000
d20 0000000000000000 d21 0000000000000000
d22 0000000000000000 d23 0000000000000000
d24 3f6efc3ffa0d967c d25 bf6efc3e566ea324
d26 4025931319798d6e d27 4000000000000000
d28 4000b7679551b393 d29 3fb59fffffffffe7
d30 3ff0000000000000 d31 40ed4c0000000003
scr 20000010

backtrace:
#00 pc 00048594 /data/app-lib/com.example.app-1/librealm-jni.so
#1 pc 0003ead7 /data/app-lib/com.example.app-1/librealm-jni.so

code around pc:
77bb1574 f8531051 eb034031 42a507c1 ebc1bf25
77bb1584 f1070202 460a0308 32fff102 4283e7ee
77bb1594 bf186858 6c08f853 44281bad b510bdf8
77bb15a4 b95a460c e9d0b96b e9d40100 42992300
77bb15b4 4290bf08 2000bf0c bd102001 0001f083
77bb15c4 2001bd10 e92dbd10 b0894ff0 4606ac12
77bb15d4 2304e9cd 0190e894 f89d9d15 1c7a3058
77bb15e4 905cf89d 6a87d103 3f01b36b b353e000
77bb15f4 0a18f10d 0b10f10d f08042bc 693380ab
77bb1604 0c01f104 21004630 202cf853 c004f8cd
77bb1614 920317d3 2306e9cd f7f69302 9a03f8e3
77bb1624 428b9b02 4282bf08 46594650 2200bf14
77bb1634 464b2201 ffb3f7ff c004f8dd f0402800
77bb1644 4664808b 6ab3e7d8 d0382c00 d90b42a3
77bb1654 e9dd6932 f852ab04 17c10024 bf084559
77bb1664 d0014550 d37742bc 0901f104 d909454b

code around lr:
77ba7ab8 f7ff7090 f504ff9b 462970b4 ff96f7ff
77ba7ac8 bd384620 000c005a 6803b508 4798695b
77ba7ad8 b508bd08 46084603 f7ff4619 f990fff5
77ba7ae8 2b003004 e8bddb03 f7ff4008 e8bdbe04
77ba7af8 f7ff4008 b537be08 6b004604 f7ff460d
77ba7b08 4669ffe3 0021e88d f7ff4620 b003fe0c
77ba7b18 e92dbd30 460441f0 46162048 460f4698
77ba7b28 f8f8f07c 46059908 ff60f7ff 46399806
77ba7b38 301cf89d 60606025 72234628 ffdbf7ff
77ba7b48 46206821 f8c1638e e8bd803c b51081f0
77ba7b58 f7ff4604 4601fdc2 e8bd4620 f7ff4010
77ba7b68 6843bfca 6818b113 bff1f7ff b5734770
77ba7b78 c9034604 0003e88d 46694620 fdd3f7ff
77ba7b88 46202100 fedaf7ff 46062101 f7ff4620
77ba7b98 4631fed5 f1044605 f7ff0048 f104ffac
77ba7ba8 46290090 ffa7f7ff 3120f894 2102b143

[kneth]

@cre8ivejp Did you have a chance to upgrade?

[cmelchior]

Since we haven't seen this particular issue surface otherwise, we can probably assume this was either a fluke or have been fixed. I'll close it for now.