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

matomick · 2017-03-24T16:11:46Z

I'm working with encrypted realm 2.3.2. and I got this issue sometimes, I really don't understand why. I'm doing nothing special when it happens...

Here is the logs:
A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x69 in tid 6254 (mmunities.debug)

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'google/bullhead/bullhead:7.1.2/NPG05D/3635581:user/release-keys'
Revision: 'rev_1.0'
ABI: 'arm64'
pid: 6254, tid: 6254, name: mmunities.debug  >>> com.facetts.communities.debug <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x69
  x0   0000000000000000  x1   0000000000000002  x2   0000000000000002  x3   0000000000000002
  x4   000000000000000c  x5   00000074886d28e4  x6   00000074886d28f0  x7   00340037006a0036
  x8   0000000000000000  x9   0000000000000000  x10  0000000000430000  x11  00000000ffffffff
  x12  0000007fe9be8558  x13  0000000000000000  x14  00000074a0a5ea88  x15  0000000000000000
  x16  0000007fe9be8680  x17  00000074a2dfa908  x18  00000074a21ec068  x19  0000007484f31e70
  x20  0000007495664400  x21  0000000000000002  x22  0000000012e83580  x23  0000000012de95c0
  x24  000000001305d790  x25  000000001305d7e0  x26  0000000012eb1400  x27  0000000012e83580
  x28  0000000012f0ce08  x29  0000007fe9be8570  x30  000000749ad120a0
  sp   0000007fe9be8570  pc   000000749ab9ea34  pstate 0000000020000000
backtrace:
  #00 pc 0000000000039a34  /data/app/com.facetts.communities.debug-2/lib/arm64/librealm-jni.so
  #01 pc 00000000001ad09c  /data/app/com.facetts.communities.debug-2/lib/arm64/librealm-jni.so
  #02 pc 00000000001ad0f8  /data/app/com.facetts.communities.debug-2/lib/arm64/librealm-jni.so
  #03 pc 00000000001ad110  /data/app/com.facetts.communities.debug-2/lib/arm64/librealm-jni.so
  #04 pc 000000000009a4a0  /data/app/com.facetts.communities.debug-2/lib/arm64/librealm-jni.so Java_io_realm_internal_UncheckedRow_nativeGetString+72)
  #05 pc 00000000008b83c0  /data/app/com.facetts.communities.debug-2/oat/arm64/base.odex (offset 0x7f3000)

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

istx25 · 2017-03-24T22:06:01Z

Hey @matomick! Thanks for reaching out about this. I'll have one of the Java engineers look into this and follow-up with you soon. Please feel free to provide any other information if you learn more before we have the chance to respond to you. Thanks!

kneth · 2017-03-27T09:39:02Z

@matomick Before I say that your issue is a duplicate of #4343, I would like to learn a bit more of how your app is accessing Realm? Do you have multiple threads reading and writing at the same thing? Does it crash "randomly" (I mean, after a while and the time span varies from run to run)?

matomick · 2017-03-27T12:45:12Z

Hi, @kneth . I'm accessing realm with 2 threads, the first one is the UI thread just for reading, and the other one to read/write, manipulate datas.
Yes it crashes randomly like you describe it.

kneth · 2017-03-28T08:45:25Z

It sounds much like #4343. Do you use plain getters or copyFromRealm()?

matomick · 2017-03-28T08:51:16Z

I'm not using copyFromRealm().

kneth · 2017-03-28T10:44:02Z

@matomick Can you provide an example/test which crashes? You are welcome to sent it to help@realm.io if you only can provide it privately. If we can provoke the crash in another way than #4343, we narrow the bug hunting.

phileo · 2017-03-28T23:55:40Z

version: "io.realm:realm-gradle-plugin:3.0.0"
encryption: enabled

I am experiencing a similar random SIGSEGV crash and I am doing the following Realm.Transaction just prior:

@Override
public void execute(Realm bgRealm) {
    bgRealm.where(AAAAA.class).findAll().deleteAllFromRealm();
    bgRealm.copyToRealmOrUpdate(result);
}

kneth · 2017-03-29T07:30:20Z

The stack trace you posted initially suggests that you are calling a getter, and the code snippet does implies that. So I assume that the SIGSEGV is from another thread. In that case I think you have the same crash as in #4343.

We are able to reproduce the bug in Realm Core (see realm/realm-core#2537), and we are working on understanding the root cause.

matomick · 2017-04-07T15:50:55Z

I got a random issue again, but i have more logs. It seems to happens only on my Nexus 5x, with Android Nougat.

A/google-breakpad: -----BEGIN BREAKPAD MICRODUMP-----
A/google-breakpad: V WebView:56.0.2924.87
A/google-breakpad: O A arm64 06 aarch64 google/bullhead/bullhead:7.1.2/NPG05D/3635581:user/release-keys
A/google-breakpad: P webview
A/google-breakpad: G OpenGL ES 3.2 V@145.0 (GIT@Idb2b4cb785)|Qualcomm|Adreno (TM) 418
A/google-breakpad: S 0 0000007FDAC117E0 0000007FDAC11000 0000000000007000
.
.
.
A/google-breakpad: -----END BREAKPAD MICRODUMP-----
W/google-breakpad: ### ### ### ### ### ### ### ### ### ### ### ### ###
W/google-breakpad: Chrome build fingerprint:
W/google-breakpad: 2.1.0
W/google-breakpad: 25
W/google-breakpad: ### ### ### ### ### ### ### ### ### ### ### ### ###
A/libc: Fatal signal 11 (SIGSEGV), code 2, fault addr 0x7771514c00 in tid 27851 (mmunities.debug)

[ 04-07 17:36:40.877 376: 376 W/ ]
debuggerd: handling request: pid=27851 uid=10213 gid=10213 tid=27851
A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
A/DEBUG: Build fingerprint: 'google/bullhead/bullhead:7.1.2/NPG05D/3635581:user/release-keys'
A/DEBUG: Revision: 'rev_1.0'
A/DEBUG: ABI: 'arm64'
A/DEBUG: pid: 27851, tid: 27851, name: mmunities.debug >>> com.facetts.communities.debug <<<
/DEBUG: signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x7771514c00
A/DEBUG: x0 000000776360c8e0 x1 0000000000000002 x2 0000007771514c00 x3 0000000000000002
A/DEBUG: x4 0000007fdac11958 x5 0000007fdac118e8 x6 000000000000001d x7 376c6b606471344d
A/DEBUG: x8 0000000000000000 x9 000000003c9d5060 x10 0000000000000000 x11 00000000ffffffff
A/DEBUG: x12 000000777e00c600 x13 0000000000000cb0 x14 000000000000000c x15 0000000000000000
A/DEBUG: x16 000000777f9895b0 x17 000000777f930e54 x18 0000000000ffffeb x19 0000007771514c00
A/DEBUG: x20 0000007763612800 x21 000000775f32ef00 x22 0000000000000000 x23 0000007fdac118c8
A/DEBUG: x24 0000000000000001 x25 00000077392b7788 x26 000000775ee18ea0 x27 0000000012d106f0
A/DEBUG: x28 0000000000000001 x29 0000007fdac117e0 x30 0000007776a9ea7c
A/DEBUG: sp 0000007fdac117e0 pc 0000007771514c00 pstate 0000000020000000
A/DEBUG: backtrace:
A/DEBUG: #00 pc 0000000000114c00 [anon:libc_malloc:0000007771400000]
A/DEBUG: #1 pc 0000000000039a78 /data/app/com.facetts.communities.debug-2/lib/arm64/librealm-jni.so
A/DEBUG: #2 pc 00000000001ad09c /data/app/com.facetts.communities.debug-2/lib/arm64/librealm-jni.so
A/DEBUG: #3 pc 00000000001ad0f8 /data/app/com.facetts.communities.debug-2/lib/arm64/librealm-jni.so
A/DEBUG: #4 pc 0000000000074b84 /data/app/com.facetts.communities.debug-2/lib/arm64/librealm-jni.so
A/DEBUG: #5 pc 000000000006ce08 /data/app/com.facetts.communities.debug-2/lib/arm64/librealm-jni.so
A/DEBUG: #6 pc 0000000000171600 /data/app/com.facetts.communities.debug-2/lib/arm64/librealm-jni.so
A/DEBUG: #7 pc 00000000001a6bd4 /data/app/com.facetts.communities.debug-2/lib/arm64/librealm-jni.so
A/DEBUG: #8 pc 000000000017d130 /data/app/com.facetts.communities.debug-2/lib/arm64/librealm-jni.so
A/DEBUG: #9 pc 000000000017e6c8 /data/app/com.facetts.communities.debug-2/lib/arm64/librealm-jni.so
A/DEBUG: #10 pc 0000000000072b64 /data/app/com.facetts.communities.debug-2/lib/arm64/librealm-jni.so (Java_io_realm_internal_TableQuery_nativeFindAll+172)
A/DEBUG: #11 pc 00000000008b58c0 /data/app/com.facetts.communities.debug-2/oat/arm64/base.odex (offset 0x7fa000)

josearaujodev · 2017-04-11T11:13:12Z

Hi guys! I'm providing here more info to help debug this, because it is happening to me in a very specific case. If, for some reason, the app account gets deleted, we are deleting everything (shared prefs, realm data, etc) and redirecting the user to the onboarding process again. The following crash is being thrown on a Nexus 5x (with OS version 7.1.1/7.1.2) :

A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x248 in tid 29689 (db-thread)
                                                                     
                                                                     [ 04-11 12:06:01.714   363:  363 W/         ]
                                                                     debuggerd: handling request: pid=29552 uid=10177 gid=10177 tid=29689

Our realm version is 3.0.0 (without encryption). We are using only one background thread for read/write on realm. I'm tracking down this issue for days, without results :|
Are there any workaround to this?

kneth · 2017-04-18T12:19:08Z

@zeluis9 From your description, what you see isn't the same as #4343 (in particular, you don't use encryption). When you "redirect the user", are all Realm instances closed? If not, I can easily image that you will see random crashes.

josearaujodev · 2017-04-18T12:42:57Z

@kneth thanks for your response. Relative to "are all Realm instances closed" I don't think this is the problem. I tried to use Realm.deleteAll() and ensured all realm instances were closed (checked with Realm.getGlobalInstanceCount(realmConfiguration)). Not worked...

kneth · 2017-04-18T12:46:15Z

@zeluis9 What do you mean by "not worked"? Didn't it delete your Realm files? Or do you see the error even if you have deleted the Realm?

josearaujodev · 2017-04-18T12:46:20Z

@kneth I don't know if this will help, but we have 35 tables. If I delete them one by one the same error is throwed. But if I try to delete data from, let's say, 10 tables, it works. That's odd

josearaujodev · 2017-04-18T12:46:55Z

@zeluis9 What do you mean by "not worked"? Didn't it delete your Realm files? Or do you see the error even if you have deleted the Realm?

The same error is throwed

kneth · 2017-04-18T13:45:04Z

@zeluis9 I would really like to see an app or test which reproduces this strange crash when deleting. Can you provide it?

josearaujodev · 2017-04-18T13:47:22Z

I think I can, but I'm busy with some other stuff at the moment. But I'll try to send it to you asap

kneth · 2017-04-18T14:42:58Z

@zeluis9 Awesome! I'll be looking forward to see it.

mariusboepple · 2017-04-28T06:01:56Z

We're facing similar crashes:

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'samsung/a5xeltexx/a5xelte:6.0.1/MMB29K/A510FXXU4BQC1:user/release-keys'
Revision: '4'
ABI: 'arm'
pid: 9158, tid: 9169, name: Binder_2  >>> com.example.app:remote <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x41
    r0 de09a24c  r1 00000000  r2 00000000  r3 00000000
    r4 f3bf7f58  r5 de09a240  r6 00000000  r7 de73e800
    r8 7fffffff  r9 f4015400  sl 0000000c  fp 00000000
    ip df3b913d  sp f3bf7f10  lr df47be7f  pc df3868c8  cpsr 200f0030

backtrace:
    #00 pc 000248c8  /data/app/com.example.app-1/lib/arm/librealm-jni.so
    #01 pc 00119e7b  /data/app/com.example.app-1/lib/arm/librealm-jni.so

We're using encrpytion and do use copyFromRealm() quite often.

mariusboepple · 2017-04-28T06:05:10Z

Another stacktrace:

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'Xiaomi/nikel/nikel:6.0/MRA58K/V8.1.6.0.MBFMIDI:user/release-keys'
Revision: '0'
ABI: 'arm64'
pid: 6370, tid: 6424, name: Worker  >>> com.example.app:remote <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x69
    x0   0000000000000000  x1   000000000000017d  x2   000000000000017d  x3   000000000000017d
    x4   0000000000430000  x5   0000000000000000  x6   0000007fa4573000  x7   0000007fa45759d0
    x8   0000000000000036  x9   0000007f8a84abb0  x10  0000000000000000  x11  0000000000000034
    x12  0000000000000001  x13  0000000000000000  x14  0000007fa4584d5c  x15  0000000000000000
    x16  0000007fa4584d58  x17  0000000000000000  x18  0000007f8a84aa00  x19  0000007f88bb9220
    x20  0000007f88457000  x21  0000000000000018  x22  0000000000000000  x23  0000000000000000
    x24  0000000032c4eac0  x25  000000003314c080  x26  000000006fbdd9b0  x27  000000006fbdd9a0
    x28  0000000000000000  x29  0000007f89672800  x30  0000007f8a5a6ddc
    sp   0000007f89672800  pc   0000007f8a42667c  pstate 0000000020000000

backtrace:
    #00 pc 000000000003967c  /data/app/com.example.app-1/lib/arm64/librealm-jni.so
    #01 pc 00000000001b9dd8  /data/app/com.example.app-1/lib/arm64/librealm-jni.so
    #02 pc 00000000001b9e34  /data/app/com.example.app-1/lib/arm64/librealm-jni.so
    #03 pc 00000000001b9e4c  /data/app/com.example.app-1/lib/arm64/librealm-jni.so
    #04 pc 0000000000092894  /data/app/com.example.app-1/lib/arm64/librealm-jni.so (Java_io_realm_internal_UncheckedRow_nativeGetString+72)
    #05 pc 000000000232864c  /data/app/com.example.app-1/oat/arm64/base.odex (offset 0x137d000)

cmelchior · 2017-05-19T13:19:31Z

We have just released 3.2.1 with what we believe is a fix for this. We discovered that our encryption implementation could, in certain race conditions, read only partly decrypted data which could cause native crashes like this.

I'm closing this issue, but please re-open it if you see this happening on 3.2.1 or above.

istx25 added the T-Help label Mar 24, 2017

istx25 assigned cmelchior Mar 24, 2017

kneth assigned kneth and unassigned cmelchior Mar 27, 2017

zaki50 added the S:Waiting For User label Mar 27, 2017

realm-ci removed the S:Waiting For User label Mar 27, 2017

kneth added the S:Waiting For User label Mar 28, 2017

realm-ci removed the S:Waiting For User label Mar 28, 2017

nhachicha added S:Waiting For User and removed S:Waiting For User labels Mar 28, 2017

kneth added S:P1 Backlog T-Bug-Crash and removed T-Help labels Mar 28, 2017

bmunkholm added S:Current Backlog and removed S:Current Iteration Backlog labels May 18, 2017

cmelchior closed this as completed May 19, 2017

cmelchior removed the S:Current Iteration Backlog label May 19, 2017

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

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

matomick commented Mar 24, 2017 •

edited by istx25

Loading

istx25 commented Mar 24, 2017

kneth commented Mar 27, 2017

matomick commented Mar 27, 2017

kneth commented Mar 28, 2017

matomick commented Mar 28, 2017

kneth commented Mar 28, 2017

phileo commented Mar 28, 2017 •

edited

Loading

kneth commented Mar 29, 2017

matomick commented Apr 7, 2017 •

edited

Loading

josearaujodev commented Apr 11, 2017 •

edited

Loading

kneth commented Apr 18, 2017

josearaujodev commented Apr 18, 2017

kneth commented Apr 18, 2017

josearaujodev commented Apr 18, 2017 •

edited

Loading

josearaujodev commented Apr 18, 2017

kneth commented Apr 18, 2017

josearaujodev commented Apr 18, 2017

kneth commented Apr 18, 2017

mariusboepple commented Apr 28, 2017 •

edited

Loading

mariusboepple commented Apr 28, 2017 •

edited

Loading

cmelchior commented May 19, 2017

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

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

Comments

matomick commented Mar 24, 2017 • edited by istx25 Loading

istx25 commented Mar 24, 2017

kneth commented Mar 27, 2017

matomick commented Mar 27, 2017

kneth commented Mar 28, 2017

matomick commented Mar 28, 2017

kneth commented Mar 28, 2017

phileo commented Mar 28, 2017 • edited Loading

kneth commented Mar 29, 2017

matomick commented Apr 7, 2017 • edited Loading

josearaujodev commented Apr 11, 2017 • edited Loading

kneth commented Apr 18, 2017

josearaujodev commented Apr 18, 2017

kneth commented Apr 18, 2017

josearaujodev commented Apr 18, 2017 • edited Loading

josearaujodev commented Apr 18, 2017

kneth commented Apr 18, 2017

josearaujodev commented Apr 18, 2017

kneth commented Apr 18, 2017

mariusboepple commented Apr 28, 2017 • edited Loading

mariusboepple commented Apr 28, 2017 • edited Loading

cmelchior commented May 19, 2017

matomick commented Mar 24, 2017 •

edited by istx25

Loading

phileo commented Mar 28, 2017 •

edited

Loading

matomick commented Apr 7, 2017 •

edited

Loading

josearaujodev commented Apr 11, 2017 •

edited

Loading

josearaujodev commented Apr 18, 2017 •

edited

Loading

mariusboepple commented Apr 28, 2017 •

edited

Loading

mariusboepple commented Apr 28, 2017 •

edited

Loading