Ported hypothesis from http://stackoverflow.com/questions/41804318/realmchangelistener-does-not-execute-when-added-shortly-after-asynchronous-write?noredirect=1#comment70833516_41804318
Realm version: 2.3.0
It is a know issue. Should be fixed on: https://github.com/realm/realm-java/pull/3834
The SO user is claiming he got it to work.
@kneth
I think this is a misunderstanding, I did not get it to work, it is just working more reliable depending on delays between the write and the queries, which is not really a solution.
I believe there might be a problem involving the "caller thread is behind the worker thread" case in the HandlerController.java.
Anyway, maybe the root cause of the problem that leads to my ChangeListener not triggering is what causes the BadVersionException (and sometimes SEGFAULT instead) when calling load() on these Results.
This is the SIGSEGV error message:
01-26 15:30:26.626 29367-29367/com.appname A/libc: Fatal signal 11 (SIGSEGV), code 2, fault addr 0x72fd8bcd20 in tid 29367 (com.appname)
[ 01-26 15:30:26.627 375: 375 W/ ]
debuggerd: handling request: pid=29367 uid=10117 gid=10117 tid=29367
01-26 15:30:26.731 29931-29931/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
01-26 15:30:26.731 29931-29931/? A/DEBUG: Build fingerprint: 'google/angler/angler:7.1.1/N4F26I/3532671:user/release-keys'
01-26 15:30:26.732 29931-29931/? A/DEBUG: Revision: '0'
01-26 15:30:26.732 29931-29931/? A/DEBUG: ABI: 'arm64'
01-26 15:30:26.732 29931-29931/? A/DEBUG: pid: 29367, tid: 29367, name: com.appname >>> com.appname <<<
01-26 15:30:26.732 29931-29931/? A/DEBUG: signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x72fd8bcd20
01-26 15:30:26.732 29931-29931/? A/DEBUG: x0 00000072fd8bcd20 x1 00000072fd8bcd20 x2 00000072faace93c x3 0000000000000001
01-26 15:30:26.732 29931-29931/? A/DEBUG: x4 0000000000000030 x5 4000000000000000 x6 0000007fff2e6b40 x7 0000000000000000
01-26 15:30:26.732 29931-29931/? A/DEBUG: x8 0000000000000001 x9 0000000000000000 x10 0000000000000000 x11 0000000000000000
01-26 15:30:26.732 29931-29931/? A/DEBUG: x12 0000000000000070 x13 000000000000001d x14 0000000000000000 x15 0000000000000002
01-26 15:30:26.732 29931-29931/? A/DEBUG: x16 0000007fff2e6bf0 x17 0000007317c23908 x18 0000000c00000000 x19 00000072fd8cd3a0
01-26 15:30:26.732 29931-29931/? A/DEBUG: x20 00000072fd8cd3a0 x21 000000731753c080 x22 00000072fd84a400 x23 000000731743e000
01-26 15:30:26.732 29931-29931/? A/DEBUG: x24 000000730d0eff70 x25 0000000012e0fca0 x26 0000000014fecee0 x27 00000072fd8cd3a0
01-26 15:30:26.732 29931-29931/? A/DEBUG: x28 0000000000000000 x29 0000007fff2e79f0 x30 00000072faa9f27c
01-26 15:30:26.732 29931-29931/? A/DEBUG: sp 0000007fff2e79f0 pc 00000072fd8bcd20 pstate 0000000060000000
01-26 15:30:26.736 29931-29931/? A/DEBUG: backtrace:
01-26 15:30:26.736 29931-29931/? A/DEBUG: #00 pc 00000000000bcd20 [anon:libc_malloc:00000072fd800000]
01-26 15:30:26.736 29931-29931/? A/DEBUG: #01 pc 0000000000033278 /data/app/com.appname-1/lib/arm64/librealm-jni.so
01-26 15:30:26.736 29931-29931/? A/DEBUG: #02 pc 0000000000072360 /data/app/com.appname-1/lib/arm64/librealm-jni.so (Java_io_realm_internal_TableQuery_nativeImportHandoverTableViewIntoSharedGroup+792)
01-26 15:30:26.736 29931-29931/? A/DEBUG: #03 pc 0000000000065340 /data/data/com.appname/cache/slice-io.realm-realm-android-library-2.3.0_0b3de97409478aa637365bab43eb294ef79e31b9-classes.dex (offset 0x70000)
@cmelchior @kneth
Would it make sense to open this again or could I create a new issue?
@benj56 I re-opened this issue
@benj56 I hope that we have a snapshot release including #3834 soon.
@kneth Would very much appreciate it. I've been looking at #3834 every few days, but can't really tell the progress. Do you think a snapshot is ready within one-two weeks? Thanks!
@benj56 #3834 is a big PR so reviewing it to a state where we can merge it, is taking longer than expected. I do hope that it is merged within two weeks from now!
@benj56 Can you reproduce this with Realm Java 3.0.0, that should contain a fix for this?
@cmelchior It is fixed, thanks.
Most helpful comment
@benj56 #3834 is a big PR so reviewing it to a state where we can merge it, is taking longer than expected. I do hope that it is merged within two weeks from now!