Crash when refreshing in background

[martinlexa]

Hi,

• Fresh git clone of the master branch, but I don't remember seeing this issue ~1 week ago. (Will try some earlier builds for regression)
• iOS 7.1 iPhone 5s device - so far, not able to reproduce this issue in a simulator
• Swift project in XCode6 Beta 5

Crashing everytime I lock the iPhone's screen.

Let me know if you need more details.

Here is the stack trace:

Thread 1
Queue : com.apple.main-thread (serial)
#0 0x000000010060170c in tightdb::util::Atomic::load_relaxed() const at /Users/tightdb/workspace/core_osx/tightdb/src/tightdb/../tightdb/util/thread.hpp:756
#1 0x00000001006018ec in tightdb::util::Atomic::load_acquire() const at /Users/tightdb/workspace/core_osx/tightdb/src/tightdb/../tightdb/util/thread.hpp:730
#2 0x00000001005fe768 in (anonymous namespace)::Ringbuffer::last() const at /Users/tightdb/workspace/core_osx/tightdb/src/tightdb/group_shared.cpp:261
#3 0x00000001005fe4e8 in tightdb::SharedGroup::get_current_version() at /Users/tightdb/workspace/core_osx/tightdb/src/tightdb/group_shared.cpp:1372
#4 0x00000001005fe484 in tightdb::SharedGroup::has_changed() at /Users/tightdb/workspace/core_osx/tightdb/src/tightdb/group_shared.cpp:866
#5 0x00000001003f5600 in -[RLMRealm refresh] at /Users/lexam/Development/iOS/realm-cocoa/Realm/RLMRealm.mm:527
#6 0x00000001003f2794 in -[RLMWeakTarget checkForUpdate] at /Users/lexam/Development/iOS/realm-cocoa/Realm/RLMRealm.mm:92
#7 0x00000001842515c4 in __NSFireTimer ()
#8 0x000000018368f704 in CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION ()
#9 0x000000018368f374 in __CFRunLoopDoTimer ()
#10 0x000000018368d09c in __CFRunLoopRun ()
#11 0x00000001835cddd0 in CFRunLoopRunSpecific ()
#12 0x00000001892b5c0c in GSEventRunModal ()
#13 0x00000001866fefc4 in UIApplicationMain ()
#14 0x00000001000c6158 in top_level_code at /Users/lexam/Development/TestApp/AppDelegate.swift:13
#15 0x00000001000c6198 in main ()
#16 0x00000001901cbaa0 in start ()

Thanks,
Martin

[bmunkholm]

Hi Martin,
Thanks for reporting this! It is not something we have seen before. It would be very helpful if we could get any code that can reproduce this bug. If any confidentiality is needed, you can email to [email protected].
Thanks!

[tgoyne]

Are you seeing this in both Debug and Release builds?

[martinlexa]

Yep, both Debug and Release builds.

I've just tried some earlier build and still see the issue, but with yesterday's commit the error changed.

Unfortunately I can't share the code, but I'll try to pin point the use case when it's happening.

[martinlexa]

I do have problems to create a simple test application to really demonstrate the issue, but I've figured out that in the app I'm working on:

If I comment out the dispatch_async parts below it won't crash => it doesn't crash when it's writing changes on the main thread.

    let queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0)
    dispatch_async(queue) {
        let realm = RLMRealm.defaultRealm()
        realm.beginWriteTransaction()

        realm.deleteObjects(A.allObjects())
        realm.deleteObjects(B.allObjects())
        realm.deleteObjects(C.allObjects())
        realm.deleteObjects(D.allObjects())
        realm.deleteObjects(E.allObjects())

        realm.commitWriteTransaction()
    }

    ...

    let queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0)
    dispatch_async(queue) {
        let realm = RLMRealm.defaultRealm()
        realm.beginWriteTransaction()

        switch objectClassName {
        case A.className():
            A.createInRealm(realm, withObject: data)
        case B.className():
            B.createInRealm(realm, withObject: data)
        case C.className():
            C.createInRealm(realm, withObject: data)
        case D.className():
            D.createInRealm(realm, withObject: data)
        case E.className():
            E.createInRealm(realm, withObject: data)
        default:
            NSLog("Error: Don't know how to store \(objectClassName) object")
        }

        realm.commitWriteTransaction()
    }

[martinlexa]

Adding backtrace.

[And simply commenting out dealloc part for _sharedGroup in RLMRealm.mm will stop crashes as well.]

(lldb) bt
* thread #22: tid = 0x2574a9, 0x0000000100641540 Realm`tightdb::util::Atomic<unsigned int>::fetch_sub_release(this=0x0000000106118458, v=2) + 28 at thread.hpp:790, stop reason = EXC_BAD_ACCESS (code=10, address=0x106118458)
    frame #0: 0x0000000100641540 Realm`tightdb::util::Atomic<unsigned int>::fetch_sub_release(this=0x0000000106118458, v=2) + 28 at thread.hpp:790
    frame #1: 0x000000010063e9dc Realm`void (anonymous namespace)::atomic_double_dec<unsigned int>(counter=0x0000000106118458) + 28 at group_shared.cpp:142
    frame #2: 0x000000010063e4f4 Realm`tightdb::SharedGroup::release_readlock(this=0x0000000145111a00, readlock=0x00000001451120c0) + 60 at group_shared.cpp:1064
    frame #3: 0x000000010063df4c Realm`tightdb::SharedGroup::end_read(this=0x0000000145111a00) + 512 at group_shared.cpp:1077
    frame #4: 0x000000010063d710 Realm`~SharedGroup(this=0x0000000145111a00) + 128 at group_shared.cpp:778
    frame #5: 0x000000010063d678 Realm`~SharedGroup(this=0x0000000145111a00) + 28 at group_shared.cpp:770
    frame #6: 0x0000000100425594 Realm`-[RLMRealm dealloc](self=0x00000001700bd220, _cmd=0x0000000186d67a90) + 320 at RLMRealm.mm:500
  * frame #7: 0x000000018417f940 Foundation`-[_NSThreadPerformInfo dealloc] + 52
    frame #8: 0x00000001835ca1d4 CoreFoundation`CFRelease + 468
    frame #9: 0x00000001835d65c0 CoreFoundation`-[__NSArrayM dealloc] + 156
    frame #10: 0x0000000184250c08 Foundation`__NSFinalizeThreadData + 1076
    frame #11: 0x00000001836892ec CoreFoundation`__CFTSDFinalize + 96
    frame #12: 0x00000001903464dc libsystem_pthread.dylib`_pthread_tsd_cleanup + 200
    frame #13: 0x00000001903461f4 libsystem_pthread.dylib`_pthread_exit + 140
    frame #14: 0x00000001903456dc libsystem_pthread.dylib`_pthread_wqthread + 388

[alazier]

I've been trying to reproduce this without success. Do you have more details regarding what else you are doing which could be causing the issue?

[alazier]

Are you still having this issue on master? We have made some changes to this part of the code base which may have an effect on the issue assuming you are still having it. One thing you could try is to set autorefresh to NO on Realm instances dispatched to background queues - this would prevent refresh from gettng called in these instances and could at least circumvent the problem.

[martinlexa]

Apologies for the delay in response. I'll test over the weekend and let you know the results.

[alazier]

I think we finally have a way to reproduce this issue with XCode6/Swift although we still haven't isolated the cause.

One way to work around the issue is to not hold onto any RLMRealm instances or RLMObject instances obtained in a background queue and to add an autorelease block around your dispatched code. This prevents refresh from being called on a background Realm and avoids the issue altogether.

[martinlexa]

Hi,

Just finished with testing using the latest code and:

• Still crashing even if I disable autorefresh on instances which are on background threads (dispatch_async) - there was a suggestion mentioned above that it may help. Doesn't seem to work for me.
• Not crashing if I put autorelease blocks around the dispatched code as was suggested by Alazier.

Thanks,
Martin

[jpsim]

@alazier @tgoyne should we keep this open? I can't reproduce this issue with the Swift TableView example on my iOS 8 device.