System.Array.IStructuralEquatable.GetHashCode Does Not Compute Hash Codes as Intended. - by Michael Graczyk

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


13
0
Sign in
to vote
ID 755995 Comments
Status Closed Workarounds
Type Bug Repros 7
Opened 7/29/2012 7:01:31 PM
Access Restriction Public

Description

This is a resubmission of the bug formerly located here:

https://connect.microsoft.com/VisualStudio/feedback/details/529636.

a cached copy can be found here:

http://webcache.googleusercontent.com/search?q=cache:BfWsi7JD3-wJ:https://connect.microsoft.com/VisualStudio/feedback/details/529636+&cd=2&hl=en&ct=clnk&gl=us

The bug is still present in .NET 4.5.  

Here is the implemenatation of GetHashCode() in Array.cs (.NET 4.0 ref source):

        int IStructuralEquatable.GetHashCode(IEqualityComparer comparer) { 
            if (comparer == null)
                throw new ArgumentNullException("comparer"); 
            Contract.EndContractBlock();

            int ret = 0;
 
            for (int i = (this.Length >= 8 ? this.Length - 8 : 0); i < this.Length; i++) {
                ret = CombineHashCodes(ret, comparer.GetHashCode(GetValue(0))); 
            } 

            return ret; 
        }

Clearly, the code:
    ret = CombineHashCodes(ret, comparer.GetHashCode(GetValue(0))); 

was intended to be:
   ret = CombineHashCodes(ret, comparer.GetHashCode(GetValue(i))); 

I say "clearly" because if the intention were to only use the length - 8th value in the computation, the code would not have included a for loop.


Fixing this small typo does not change the execution time of method, does not change the size of the IL, and only increases the size of the JIT'ed code by 2 or 3 bytes.  

Similarly, fixing this typo will not break any code unless the code were written to be pathologically dependent on the the behavior of IStructuralEquatable.GetHashCode. 



Sign in to post a comment.
Posted by George Chakhidze on 6/19/2014 at 2:17 AM
This bug has nothing to do with Visual Studio 2013 and it's updates. It is present in mscorlib.dll, which is not part of Visual Studio.
I can still reproduce this bug on .NET Framework 4.5.2 (Runtime version 4.0.30319.34209). I have Visual Studio 2013 with Update 2 installed.
Posted by Microsoft on 6/6/2014 at 9:53 AM
Thank you for using Visual Studio and for reporting this bug. We are happy to let you know that this issue has been fixed in Visual Studio 2013 Update 2. If you already have Visual Studio 2013, you can upgrade to Update 2 for free or you can install a trial version from: http://go.microsoft.com/?linkid=9832436
Posted by piers7 on 12/19/2013 at 7:48 PM
We tracked a significant performance problem in our system down to this bizarre implementation. We were using a Dictionary<object[],object[]> as a cache, using a StructualEqualityComparer to coalesce 'equivalent' entries. The consequence of this implementation was the dictionary distributed our 180k entries over just 16 buckets, resulting in *extremely* slow dictionary insert/lookup performance.

If I'd wanted a broken hashcode implementation, I'd have written my own :-/
Posted by Microsoft on 7/30/2012 at 1:54 AM
Thank you for submitting feedback on Visual Studio 11 and .NET Framework. Your issue has been routed to the appropriate VS development team for review. We will contact you if we require any additional information.
Posted by Microsoft on 7/29/2012 at 7:53 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)