Realm-dotnet: Crash with MvxRecyclerView using MvvmCross and Realm 1.2.0
After updating from 1.1.1 to 1.2.0 version, there is crash during scrolling back with MvxRecyclerView (MvvmCross https://github.com/MvvmCross/MvvmCross) and RealmObjects as source.
Sample project, to reproduce the crash: https://github.com/voluntas88/RealmMvvmCrossRecyclerView
MvxRecyclerView has collection of RealmObjects as Source. The MvxRecyclerView item is binded to RealmObject properties.
After app launch, MvxRecyclerView is correctly loaded and populated with data.
Scroll list forward and then start to scrolling it back. At that moment the crash is occurred with error:
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.F/libc ( 5719): Fatal signal 11 (SIGSEGV), code 1, fault addr 0x8 in tid 5747 (Thread-47753)
Version 1.1.1 works well with sample code.
voluntas88
All 14 comments
I have the same issue however haven't been able to make a repo to reproduce. Hopefully the repo provided is enough to track down the issue.
EmmanVazz
on 11 Apr 2017
Same.
justinimel
on 11 Apr 2017
Thanks for the report and the repro case! I'll try to look into it tomorrow.
nirinchev
on 11 Apr 2017
Is there any news on this issue?
On Apr 10, 2017, at 6:17 PM, Nikola Irinchev notifications@github.com wrote:
Thanks for the report and the repro case! I'll try to look into it tomorrow.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
EmmanVazz
on 17 Apr 2017
Seems like this is affecting a hand full of us. Any update? Anything helpful in the latest 1.2.1 release? Thanks!
EmmanVazz
on 1 May 2017
Unfortunately 1.2.1 was more of a maintenance release to update the Fody dependency, so no progress there. On the bright side, we've recently fixed a few bugs related to notifications (which is the underlying cause of the crash here). If you're willing to test a pre-release nuget, here it is. With this version, I am no longer able to reproduce the crash on a simulator.
Be aware though, that it's a prerelease version, so it hasn't been thoroughly tested and may introduce regressions or other issues.
nirinchev
on 1 May 2017
I'm getting this crash as well, will give the pre-release nuget a go and see if that helps. Cheers.
UKDeveloper99
on 2 May 2017
That seems to be working although I'm now getting a System.ObjectDisposedException. Will investigate the cause of that and report back.
UKDeveloper99
on 2 May 2017
Are you getting it with the repro project from the first post or with your own app? I think the only realm object that may throw it is the Realm class if you attempt to call methods that should reach the database (i.e. most public methods). I'll leave the issue open a few more days so more people can check if the crashes disappear.
nirinchev
on 2 May 2017
Gave it a test on iOS and droid. The issue seems to be solved. Also I don't get the System.ObjectDisposedException exception that was mentioned.
EmmanVazz
on 2 May 2017
One of my own projects, the MvxRecyclerView is bound to an IRealmCollection. About every 40 seconds the database updates all the objects in the bounded list with new (unmanaged versions) using Add(update:true, obj). The exception seems to firing on the line _realm.Write(() => ...). I'm getting cannot access a disposed object System.ObjectDisposedException and the object name is MvvmCross.Binding.Droid.Views.MvxAdapter. If I just leave it updating it seems to occur randomly, so it could update the realm objects 5 or 6 times before the exception occurs. Any ideas? I'll attempt to debug it further.
UKDeveloper99
on 3 May 2017
mvx:Warning:130.37 Exception masked during Adapter RealNotifyDataSetChanged ObjectDisposedException: Cannot access a disposed object.
Object name: 'MvvmCross.Binding.Droid.Views.MvxAdapter'.
at Java.Interop.JniPeerMembers.AssertSelf (Java.Interop.IJavaPeerable self) [0x00030] in /Users/builder/data/lanes/4468/b16fb820/source/Java.Interop/src/Java.Interop/Java.Interop/JniPeerMembers.cs:153
at Java.Interop.JniPeerMembers+JniInstanceMethods.InvokeVirtualVoidMethod (System.String encodedMember, Java.Interop.IJavaPeerable self, Java.Interop.JniArgumentValue* parameters) [0x00002] in /Users/builder/data/lanes/4468/b16fb820/source/Java.Interop/src/Java.Interop/Java.Interop/JniPeerMembers.JniInstanceMethods_Invoke.cs:21
at Android.Widget.BaseAdapter.NotifyDataSetChanged () [0x00000] in /Users/builder/data/lanes/4468/b16fb820/source/monodroid/src/Mono.Android/platforms/android-25/src/generated/Android.Widget.BaseAdapter.cs:297
at MvvmCross.Binding.Droid.Views.MvxAdapter.RealNotifyDataSetChanged () [0x00000] in <6a0c851a22864d0993089d65320a630c>:0 . Are you trying to update your collection from a background task? See http://goo.gl/0nW0L6
I believe the System.ObjectDisposedException is unrelated. At some point something is getting garbage collected. I think you can consider the main issue fixed, which has disappeared for me. I'll open a separate issue if I can tie this exception to Realm. Which I'm not 100% is the cause as yet.
UKDeveloper99
on 3 May 2017
So I fixed the issue that was giving me System.ObjectDisposedException, on the off-chance that it might help anyone reading this topic I'll explain the cause and solution. A lot of the time with MvvmCross there is a need to subclass the adapter to add some custom logic. In my particular case I had my own custom adapter subclass inherited from Mvx.Adapter. Setting a custom adapter with mvvmcross requires you to set it programmatically in code, on the widget. E.g. For an Mvx.GridView you would do gridview.Adapter = new MyCustomAdapter() then create the binding programmatically because the binding can't be done via XML.
In my case I had forgotten to remove the mvx:bind call from the XML file, so when the view was inflated the widget was databinded to the original mvx adapter and then immediately after to the new custom adapter. Because the original adapter was most likely garbage collected after a while, somehow Realm was still trying to reference it for the first binding. I guess Realm was then propagating this System.ObjectDisposedException when it tried to fire collection changed notifications on the original adapter, which no longer existed.
So there you go, make sure you remove you're xml bindings if you bind in code =)
UKDeveloper99
on 3 May 2017
Related issues
Amor-Fairouz
·
15Comments
tuyen-vuduc
·
9Comments
salgiza
·
10Comments
jitendrajadav
·
12Comments
AndyDentFree
·
7Comments
Most helpful comment
So I fixed the issue that was giving me
System.ObjectDisposedException, on the off-chance that it might help anyone reading this topic I'll explain the cause and solution. A lot of the time with MvvmCross there is a need to subclass the adapter to add some custom logic. In my particular case I had my own custom adapter subclass inherited fromMvx.Adapter. Setting a custom adapter with mvvmcross requires you to set it programmatically in code, on the widget. E.g. For anMvx.GridViewyou would dogridview.Adapter = new MyCustomAdapter()then create the binding programmatically because the binding can't be done via XML.In my case I had forgotten to remove the
mvx:bindcall from the XML file, so when the view was inflated the widget was databinded to the original mvx adapter and then immediately after to the new custom adapter. Because the original adapter was most likely garbage collected after a while, somehow Realm was still trying to reference it for the first binding. I guess Realm was then propagating thisSystem.ObjectDisposedExceptionwhen it tried to fire collection changed notifications on the original adapter, which no longer existed.So there you go, make sure you remove you're xml bindings if you bind in code =)