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

Mysterious detached-row exceptions #746

Closed
kristiandupont opened this issue Aug 2, 2016 · 26 comments · Fixed by #751
Closed

Mysterious detached-row exceptions #746

kristiandupont opened this issue Aug 2, 2016 · 26 comments · Fixed by #751
Milestone

Comments

@kristiandupont
Copy link
Contributor

kristiandupont commented Aug 2, 2016

A number of users have been experiencing detached row exceptions in data binding scenarios. This started appearing after the release of 0.77.0/0.77.1.

@UKDeveloper99
Copy link

I'm going to make another attempt to reproduce it in my test project when I've a got a spare moment.

@kristiandupont
Copy link
Contributor Author

@UKDeveloper99 and @CrimsonKyle, is there any way either of you could share your code with us? It will be treated completely confidentially and we can sign an NDA if necessary. Alternatively, could we set up a screen sharing session where one of us could debug on your machine? We have not been able to reproduce the bug so far.

AndyDentFree added a commit that referenced this issue Aug 2, 2016
AndyDentFree added a commit that referenced this issue Aug 2, 2016
AndyDentFree added a commit that referenced this issue Aug 2, 2016
put back the NUnit command in the project as that is not the runner - it is run by the Jenkins script
**downgraded** the NUnit version in the package in case that affects console run in Jenkins CI
@CrimsonKyle
Copy link

@kristiandupont I just got the green light for a screen share web conference with you to allow us to debug the issue. What times work best for your team? We are in central standard time.

@UKDeveloper99
Copy link

@kristiandupont I've reproduced it in a test project, uploading it to my dropbox now.

@CrimsonKyle
Copy link

@UKDeveloper99 I was actually just about to say we have made a test project also lol

@UKDeveloper99
Copy link

UKDeveloper99 commented Aug 2, 2016

@CrimsonKyle The more test projects the better 😄

@AndyDentFree
Copy link
Contributor

Great news, thanks. If you can't post the dropbox URLs here please send them to help@realm.io and Kristian and I can look at them.

@AndyDentFree
Copy link
Contributor

I have spent today doing a partitioning exercise separating out the IList changes and DetachedRow detection in 0.77.1 from all the other changes, so with these test projects we should be able to get to a quick answer.

@AndyDentFree
Copy link
Contributor

Thanks @UKDeveloper99 I have triggered the error on my machine with your sample.

@CrimsonKyle
Copy link

We are sending our test project link now @UKDeveloper99 can you send us the link to yours so we can ensure it is replicating the issue in the same way?

@UKDeveloper99
Copy link

@CrimsonKyle What's your e-mail and I'll send you the link.

@UKDeveloper99
Copy link

UKDeveloper99 commented Aug 2, 2016

Got it, you can delete that post now if you don't want your e-mail hanging around on here.

Just an fyi, the code in there is a bit of a mish mash from an old tutorial and parts of my actual app. So if it doesn't make any sense don't worry about it 😄 All the realm code is in the KittenListService class.

@AndyDentFree
Copy link
Contributor

@CrimsonKyle have reproduced with clicking on different items in the list (in IOS sim)

@AndyDentFree
Copy link
Contributor

This is interesting/frustrating - the two samples are utterly different and the problem comes up with radically different stack crawls.

@UKDeveloper99 I get a crash getting a string property at the bottom of a lot of data binding through MVVMCross for pure IOS.

@CrimsonKyle I get a crash trying to load related list of dogs, in a Xamarin Forms UI.

@AndyDentFree
Copy link
Contributor

AndyDentFree commented Aug 2, 2016

In both cases, the problem is triggered by having RealmObjects around after the Realm from which they were obtained has gone out of scope. In the Forms UI, it is triggered when you go down into a nested list then come back up, with GetInstance called again resetting the field in that GUI object.

In @UKDeveloper99 's Sandbox, the Realm is only going into a local variable but objects are passed out of that context.

There is also a problem happening in @CrimsonKyle's sample which may be an unrelated problem, but with the same cause - Realm instances are getting cleaned up by the Fnalizer running on a different thread. (Update later - the finalizer issue is separate and unrelated and ironically was fixed in 0.77.1.)

@UKDeveloper99
Copy link

UKDeveloper99 commented Aug 3, 2016

@AndyDentFree Is there an easy fix? I'm guessing the same thing was happening but Realm wasn't picking it up in 0.76.1?
Thinking out loud, it seems a little flawed to me. In a simple use case scenario, you get stuff out the database then you expect to be able to pass it around and do things with it. If it still relies on the Realm being in scope that's very constricting.

@AndyDentFree
Copy link
Contributor

in the sample from @CrimsonKyle use the Realm in the App class

  1. make _realm in the App class internal access
  2. In RootPage.cs and DetailList.cs use that instance:
_realm = ((realmIssue746.App)App.Current)._realm;  
// instead of _realm = Realm.GetInstance();

In the Sandbox sample from @UKDeveloper99 it was a little harder to work out where to put things but the same style of fix works - just hang onto the Realm instance for the duration.

This is not necessarily the best architecture but to prove robustness, I added a singleton in KittenModel.cs


    public static class KittenDB
    {
        private static Realm _realm;
        public static Realm db {
            get {
                if (_realm == null)
                    _realm = Realm.GetInstance("KittensRealm.realm");
                return _realm;
            }
        }
    }

Then getting an instance used that property:

var db = KittenDB.db;  
// instead of var db = Realm.GetInstance("KittensRealm.realm");

@nirinchev
Copy link
Member

@AndyDentFree while this will probably work as a crude workaround, isn't it a little dangerous to expose realms as statics, considering they may be accessed from any thread? I'm just concerned about people grabbing that snippet and then hitting concurrency issues.

Since there are a few people to hit that problem, perhaps the docs should indicate it more explicitly that Realm instances should stay alive for at least as long as the objects retrieved from them.

@AndyDentFree
Copy link
Contributor

@nirinchev Yes you make a great point - I just wanted to get these folks over an immediate hump whilst we are digging deeper into the why of this (these?) bugs. We need more samples and documentation on best practices.

We didn't have any integration testing which covered the scenarios here, of a Realm instance being disposed whilst objects from it are still live and are still trying to work out exactly how that is happening.

AndyDentFree added a commit that referenced this issue Aug 3, 2016
Removed verify_thread call from ObjectStore Realm::close so delete on finalisers is OK
@Shazbot89
Copy link

@AndyDentFree Is the work around to "...use the Realm in the App class" to detach the instance from the lifecycle of Xam.Forms pages? Trying to make sure I understand.

@AndyDentFree
Copy link
Contributor

The workaround is to keep the Realm around for as long as you have objects referring to it.

A cleaner way is to have a ViewModel class that owns a Realm instance.

We are working very hard on this because it should just work and a much smaller subset of the 0.77.1 changes has been identified as triggering this behaviour.

@CrimsonKyle
Copy link

CrimsonKyle commented Aug 3, 2016

@AndyDentFree creating the below class and adding the following to the constructor has solved 90% of our issues for the last 10% we are still breaking with the "detached row error message" when our background update process runs and updates the realm while we are accessing a RealmResult that has been converted to a list of realm objects in a UI element but that might be more related to how our Sync Gateway® @Shazbot89 works and not realm.

public static class RealmDB
    {
        private static Realm _realm;
        public static Realm db
            {
                get
                {
                    if (_realm == null)
                        _realm = Realm.GetInstance();
                    return _realm;
                }
            }
    }

Then every class we access realm we put the following in the constructor:

try
{
    _realm = RealmDB.db;
}
catch (Exception e)
{
    Console.WriteLine(e);
}

AndyDentFree added a commit that referenced this issue Aug 4, 2016
….1.2

Noticed that the tagged v0.76.1 had advanced to core 1.1.2 but for some reason the master I based this on was only 1.0.2
AndyDentFree added a commit that referenced this issue Aug 4, 2016
@CrimsonKyle
Copy link

Just wanted to say with 0.77.2 it looks like it fixed everything much thanks! I know you all put a lot of work into getting ILists working so great job!

@Harvinator
Copy link

Just wanted to add my experience for anyone coming here with a rogue "Attempted to access detached row" error.

My problem was that my ViewController had an event listener to a static object which wasn't being removed. (I'd put the code to remove the handler in ViewDidUnload (which doesn't always get fired).

So what was happening was the RealmObject in question was being removed from the realm after the view was closed. Then if i opened the ViewController again the event was actually being fired on both the new & old instance of the ViewController (and the old one was referencing the removed RealmObject)

So a good thing that realm complained about it or I wouldn't have noticed the memory leak (although it was a difficult to debug).

@egeniegithub
Copy link

I am also having this same issue
In ViewDidLoad(). I am traversing the list in for loop and getting value of one property from each object. which then gives me crash on same line.

@nirinchev
Copy link
Member

This issue has been fixed and what you're observing is unlikely to be related to it. Please file a new one and provide as much detail as possible so we can help you investigate.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 15, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants