.NET Native bug and solution

Discuss any questions about BEPUphysics or problems encountered.
Post Reply
duke
Posts: 7
Joined: Sat Jul 02, 2011 11:06 am

.NET Native bug and solution

Post by duke »

I am using BEPU Physics to make a Windows UWP app. I have made the necessary source code changes most of which are described here viewtopic.php?f=4&t=1926&p=11288.

Everything seemed to work perfectly until I did a .NET Native build. That's when I started getting a System.IndexOutOfRangeException in IntertiaHelper.GenerateSphere(). After spending hours investigating this, it turns out that the calls to edges.TryGetValue() are not working as expected i.e. it is returning false for edges that have already been added to the edges Dictionary (but only in a .NET Native build).

Finally I came across this piece of documentation that helped me find a solution. https://msdn.microsoft.com/en-us/librar ... .110).aspx. The relevant bit being...
If you implement IEquatable<T>, you should also override the base class implementations of Object.Equals(Object) and GetHashCode so that their behavior is consistent with that of the IEquatable<T>.Equals method.
I saw that TriangleMeshConvexContactManifold.Edge implements IEquatable but does not override the base class Object.Equals() so I provided an implementation as follows:

Code: Select all

            public override bool Equals(object obj)
            {
                return this.Equals((Edge)obj);
            }
Hey presto, it stopped the exception but I was still getting strange behaviour when running the physics engine in .NET Native. I went back and searched the entire code base for classes that implement IEquatable and added the Equals override where it was missing. And now it alls seems to work perfectly.

I'm not sure if this is a .NET Native bug or BEPU Physics bug but I hope this is helpful.
Last edited by duke on Sun Dec 13, 2015 10:22 pm, edited 1 time in total.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: .NET Native bug and solution

Post by Norbo »

This is worrisome- it implies that the native build is actually using the Equals(object) methods.

It sounds like EqualityComparer<T>.Default isn't returning IEquatable<T>-based comparers under .NET Native, or it's not being used in the same way inside the default collections. This would be a pretty nasty breaking change if true. In addition to the correctness issue you've run into, it is likely also creating a bunch of garbage via boxing unless .NET native does something tricky.

Explicitly passing in an equality comparer to the collection constructor or using the custom Quick collection variants should solve the issue either way, but I'll have to look into it more.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: .NET Native bug and solution

Post by Norbo »

It appears that EqualityComparer<T>.Default does in fact return a boxing implementation under .NET native. I submitted a connect issue about it; voting on it would be helpful.

I'm not sure what I want to do about a workaround yet. I might just be lazy about it, hoping that it gets fixed or BEPUphysics v2 gets done before too many people run into this.
duke
Posts: 7
Joined: Sat Jul 02, 2011 11:06 am

Re: .NET Native bug and solution

Post by duke »

Thanks for the quick reply to this, I have up-voted the connect issue!

Hopefully Microsoft will fix this in .NET Native. In the meantime your suggested workarounds should hopefully avoid the boxing issue. Thanks again!
Post Reply