objectbox-java: Crash when removing relation and related entity

When I upgrade app it would crash when init objectbox, logcat is below:

    --------- beginning of crash
07-02 10:41:32.395 7478-7519/com.gnet.uc A/libc: Fatal signal 11 (SIGSEGV), code -6, fault addr 0x1d36 in tid 7519 (Thread-4)
07-02 10:41:32.397 404-404/? I/MIUINDBG_HOOK: hook hook_sigtimedwait
07-02 10:41:32.477 7524-7524/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
07-02 10:41:32.478 7524-7524/? A/DEBUG: Build fingerprint: 'Xiaomi/helium/helium:7.0/NRD90M/V9.5.2.0.NBDCNFA:user/release-keys'
    Revision: '0'
    ABI: 'arm'
    pid: 7478, tid: 7519, name: Thread-4  >>> com.gnet.uc <<<
    signal 11 (SIGSEGV), code -6 (SI_TKILL), fault addr 0x1d36
07-02 10:41:32.479 7524-7524/? A/DEBUG:     r0 00000000  r1 00000012  r2 e31ec381  r3 00000000
        r4 e12cdce0  r5 e12cdd54  r6 00009be7  r7 ccbcb1f0
        r8 00000000  r9 ccbcb3a4  sl 00000000  fp 00000000
        ip cca71e70  sp ccbcb168  lr cc997775  pc cc9c1c86  cpsr 600b0030
07-02 10:41:32.484 7524-7524/? A/DEBUG: backtrace:
        #00 pc 000b4c86  /data/app/com.gnet.uc-1/lib/arm/libobjectbox.so (_ZNK9objectbox6Schema20getEntityByIdOrThrowEj+21)
        #01 pc 0008a771  /data/app/com.gnet.uc-1/lib/arm/libobjectbox.so (_ZN9objectbox6Cursor22getForeignEntityCursorEj+80)
        #02 pc 0008ac1f  /data/app/com.gnet.uc-1/lib/arm/libobjectbox.so (_ZN9objectbox6Cursor16findBacklinkKeysEPNS_8PropertyEyRNSt6__ndk16vectorIyNS3_9allocatorIyEEEE+58)
        #03 pc 0008a69b  /data/app/com.gnet.uc-1/lib/arm/libobjectbox.so (_ZN9objectbox6Cursor14clearBacklinksEy+86)
07-02 10:41:32.485 7524-7524/? A/DEBUG:     #04 pc 0008a335  /data/app/com.gnet.uc-1/lib/arm/libobjectbox.so (_ZN9objectbox6Cursor6removeEv+336)
        #05 pc 0008c351  /data/app/com.gnet.uc-1/lib/arm/libobjectbox.so (_ZN9objectbox6Cursor9removeAllEv+86)
        #06 pc 000bb7ed  /data/app/com.gnet.uc-1/lib/arm/libobjectbox.so (_ZN9objectbox8SchemaDb23removeEntityWithAllDataEPKNS_6EntityE+36)
        #07 pc 000bfa09  /data/app/com.gnet.uc-1/lib/arm/libobjectbox.so (_ZN9objectbox10SchemaSync10syncSchemaERNS_13SchemaCatalogERNS_6SchemaES4_+520)
        #08 pc 000bc271  /data/app/com.gnet.uc-1/lib/arm/libobjectbox.so (_ZN9objectbox10SchemaSync4syncENSt6__ndk110shared_ptrINS_6SchemaEEEPKNS_5model5ModelE+248)
        #09 pc 000bbe7f  /data/app/com.gnet.uc-1/lib/arm/libobjectbox.so (_ZN9objectbox10SchemaSync4syncEPKNS_5model5ModelE+154)
        #10 pc 000cead3  /data/app/com.gnet.uc-1/lib/arm/libobjectbox.so (Java_io_objectbox_BoxStore_nativeCreate+170)
        #11 pc 02ddf20d  /data/app/com.gnet.uc-1/oat/arm/base.odex (offset 0x2d7c000)

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 18 (8 by maintainers)

Most upvoted comments

@greenrobot I have a reliable reproduction for this case in the form of this repo: https://github.com/raja-baz/objectbox-490-reproduction

Steps to reproduce:

Check out commit 8a5070a28bb23f1108d60e56b181a67bd9513838
Run the app
Check out commit 1243aac8fa6fdf46892395cd89646592a695d916
Run the app => Experience the crash

This seems to be an issue during migration when an entity which is used as a target for a relation is removed. Some additional tests show that:

If the data is not populated yet, the migration will go through successfully. To test this, run the commits in this order:
1. 17128fb36b706425377ca30eee4769133c6c8ff8
2. 1243aac8fa6fdf46892395cd89646592a695d916
If we have an intermediate migration where the relation is removed, but not the target entity, the migration also goes through fine. Run the commits in this order to test:
1. 8a5070a28bb23f1108d60e56b181a67bd9513838
2. 26ad20eb8aefa87c2749e58947462fcea0aad596
3. 1243aac8fa6fdf46892395cd89646592a695d916

For now, we’ve decided to keep the legacy entities and not delete them to work around this issue while just not using them. Obviously this isn’t ideal, but a segfault on app launch is even less ideal 😛

Cheers

PS: This is on latest object box(2.1) and the crash in question is:

11-07 12:58:07.823 15770 15770 F libc    : Fatal signal 11 (SIGSEGV), code 1, fault addr 0x20 in tid 15770 (m.objectboxtest)
11-07 12:58:07.842 15794 15794 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
11-07 12:58:07.842 15794 15794 F DEBUG   : Build fingerprint: 'Android/sdk_gphone_x86_64/generic_x86_64:8.0.0/OSR1.180418.007/5071102:userdebug/dev-keys'
11-07 12:58:07.842 15794 15794 F DEBUG   : Revision: '0'
11-07 12:58:07.842 15794 15794 F DEBUG   : ABI: 'x86_64'
11-07 12:58:07.842 15794 15794 F DEBUG   : pid: 15770, tid: 15770, name: m.objectboxtest  >>> anghami.com.objectboxtest <<<
11-07 12:58:07.842 15794 15794 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x20
11-07 12:58:07.842 15794 15794 F DEBUG   : Cause: null pointer dereference
11-07 12:58:07.842 15794 15794 F DEBUG   :     rax 00007ffe8574c720  rbx 0000000000000000  rcx 0000000000000002  rdx 0000000000000000
11-07 12:58:07.842 15794 15794 F DEBUG   :     rsi 0000000000000001  rdi 0000000000000000
11-07 12:58:07.842 15794 15794 F DEBUG   :     r8  ffffffffffffffe0  r9  00007056f9a27208  r10 00007056f9a27208  r11 00007056fd1beca8
11-07 12:58:07.842 15794 15794 F DEBUG   :     r12 0000000000000000  r13 0000000000000000  r14 00007056ec1ef668  r15 00007056ec1ef500
11-07 12:58:07.843 15794 15794 F DEBUG   :     cs  0000000000000033  ss  000000000000002b
11-07 12:58:07.843 15794 15794 F DEBUG   :     rip 00007056e214e1d4  rbp 00007056f9a2dc68  rsp 00007ffe8574c230  eflags 0000000000010246
11-07 12:58:07.844 15794 15794 F DEBUG   :
11-07 12:58:07.844 15794 15794 F DEBUG   : backtrace:
11-07 12:58:07.844 15794 15794 F DEBUG   :     #00 pc 000000000008d1d4  /data/app/anghami.com.objectboxtest-W3dHK5lUXMLiGBZ028womw==/lib/x86_64/libobjectbox.so
11-07 12:58:07.844 15794 15794 F DEBUG   :     #01 pc 000000000004bad9  /data/app/anghami.com.objectboxtest-W3dHK5lUXMLiGBZ028womw==/lib/x86_64/libobjectbox.so
11-07 12:58:07.844 15794 15794 F DEBUG   :     #02 pc 000000000004d5be  /data/app/anghami.com.objectboxtest-W3dHK5lUXMLiGBZ028womw==/lib/x86_64/libobjectbox.so
11-07 12:58:07.845 15794 15794 F DEBUG   :     #03 pc 000000000004d34d  /data/app/anghami.com.objectboxtest-W3dHK5lUXMLiGBZ028womw==/lib/x86_64/libobjectbox.so
11-07 12:58:07.845 15794 15794 F DEBUG   :     #04 pc 000000000008f9d6  /data/app/anghami.com.objectboxtest-W3dHK5lUXMLiGBZ028womw==/lib/x86_64/libobjectbox.so
11-07 12:58:07.845 15794 15794 F DEBUG   :     #05 pc 000000000009416f  /data/app/anghami.com.objectboxtest-W3dHK5lUXMLiGBZ028womw==/lib/x86_64/libobjectbox.so
11-07 12:58:07.845 15794 15794 F DEBUG   :     #06 pc 0000000000090db4  /data/app/anghami.com.objectboxtest-W3dHK5lUXMLiGBZ028womw==/lib/x86_64/libobjectbox.so
11-07 12:58:07.845 15794 15794 F DEBUG   :     #07 pc 0000000000090a7f  /data/app/anghami.com.objectboxtest-W3dHK5lUXMLiGBZ028womw==/lib/x86_64/libobjectbox.so
11-07 12:58:07.845 15794 15794 F DEBUG   :     #08 pc 0000000000041f06  /data/app/anghami.com.objectboxtest-W3dHK5lUXMLiGBZ028womw==/lib/x86_64/libobjectbox.so
11-07 12:58:07.845 15794 15794 F DEBUG   :     #09 pc 000000000001b23f  /data/app/anghami.com.objectboxtest-W3dHK5lUXMLiGBZ028womw==/lib/x86_64/libobjectbox.so (Java_io_objectbox_BoxStore_nativeCreate+191)
11-07 12:58:07.845 15794 15794 F DEBUG   :     #10 pc 000000000000a532  /data/app/anghami.com.objectboxtest-W3dHK5lUXMLiGBZ028womw==/oat/x86_64/base.odex (offset 0xa000)
11-07 12:58:07.845 15794 15794 F DEBUG   :     #11 pc 0000000000000013  <unknown>

raja-baz on Nov 7, 2018

@greenrobot I was having this same issue and I don’t see it anymore with 2.4.0-RC

Schrobie on Oct 17, 2019

@greenrobot , any updates on the bug fix?

I encountered similar crash as well. After the app is published, users will encounter crash, if they update the app while the app is running (background). However, if they clear the app (not running in background) before updating it, everything works fine.

dillonc17 on Jun 28, 2019

@raja-baz Thanks for your repro project, could verify the crash. Using this issue is fine as the original reporter has not responded.

Passed this on to the development team. -ut

greenrobot-team on Nov 13, 2018