Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash when refreshing in background #773

Closed
martinlexa opened this issue Aug 12, 2014 · 11 comments
Closed

Crash when refreshing in background #773

martinlexa opened this issue Aug 12, 2014 · 11 comments
Labels

Comments

@martinlexa
Copy link

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
Copy link
Contributor

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 help@realm.io.
Thanks!

@tgoyne
Copy link
Member

tgoyne commented Aug 12, 2014

Are you seeing this in both Debug and Release builds?

@martinlexa
Copy link
Author

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.

debug_2
debug_1

@martinlexa
Copy link
Author

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
Copy link
Author

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

@bmunkholm bmunkholm added the bug label Aug 13, 2014
@alazier
Copy link
Contributor

alazier commented Aug 15, 2014

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
Copy link
Contributor

alazier commented Aug 22, 2014

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
Copy link
Author

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

@alazier
Copy link
Contributor

alazier commented Aug 29, 2014

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
Copy link
Author

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
Copy link
Contributor

jpsim commented Oct 14, 2014

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

@alazier alazier closed this as completed Oct 14, 2014
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 18, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

5 participants