Skip to main content

Interesting bug - Line endings and Hash Code


I recently came across an interesting bug which emphasize how different line endings format can break your custom equality implementation if you do not carefully consider them.

 Context
We have an application that periodically updates the local assets with latest updated resources. In a nutshell, it makes an web api call to get the latest set of metadata and compare them against a locally stored metadata file. If they differs then we update the locally stored metadata file and download new/updated resources.

Bug
For a particular asset, associated metadata file was always getting updated although there were no visible changes detected using the revision history.

Investigation
My obvious suspect was the code responsible for doing the equality check between local metadata and the metadata received from the Web API.

For verification, I setup a conditional break-point which will be hit when the equality returns false. After my debug hit the break-point, I looked into all the properties and found that one of them was returning false. It was a list of tag objects and we were doing an HashSet equality comparison on that list. Something similar to below pseudo code:


Although, I had narrowed down the issue it was still not clear which object from the list was actually throwing the equality to false. So I decided to look into the hash-codes for this two list of objects.

Upon looking into the hash code, I discovered that one of the hash-code was different between the compared objects which happened to be at position 3. A quick lookup on the value at that position and viola!. One of them contains line endings as '\r\n' = CR + LF while the one from the web api contains '\n' = LF.

Most text editor will not display the different line endings in default view also line endings could be OS specific. Hence, it seems like nothing has been changed in the file. However, as they contains different values my custom equality implementation along with the get hash-code function generates different hashes for them and thus the equality returned false.

Here is a simplified version of the original class which implements IEquatable of T


Fix

Updating the object property getter to use consistent line ending. Basically doing a Regex replace with a '\r\n'.

After the above change is in place,  hash-code and hence the equality will be same for object with different line endings format. This will give us the expected result and our metadata file will not get unnecessarily updated.


Lesson Learned

Be mindful of different line endings, null values and sometimes different culture settings when implementing a custom equality based on string properties.


Labels:

Comments

The Local Guys – Pest Control said…
Amazingly helpful which you have shared here. I am impressed by the details and also it is a significant article for termite control in brisbane us. Continue imparting this sort of info, Thank you.
December 4, 2022 at 1:26 AM
Post a Comment

Popular posts from this blog

Creating dynamic email templates using C# and Office Outlook

It is quite common for many applications to send automated email notifications. Couple of months ago, I have worked on improving our old email template format to make it more user friendly . In this tutorial I will walk you though regarding how I took advantage of Microsoft Outlook to quickly generate custom email template and later using the html template for building an automated custom email application using C#. Steps: Creating Templates: Using the rich text editor support  in Outlook create a nicely formatted email. Use placeholder text for the values you like to change dynamically based on your task completion status. To keep this tutorial simple, I have created a  simple table with placeholder text inside the third bracket  [place holder text]. However, you can use anything supported by outlook editor. Figure: Email Template Getting HTML code: Send the created email to your own address. After that, open the sent email and right click to view source . It
5 comments
Read more

Why using XOR might not be a good hash code implementation?

Using XOR for computing hash codes works great for most of the cases specially when order of computation does not matter. It also has the following benefits: XOR has the best bit shuffling properties of all bit-operations and provides better distributions of hash values. It is a quick single cycle operation in most computer  Order of computation does not matter. i.e. a^b = b^a However, if ordering of elements matter then it is often not a good choice. Example For simplicity consider you have a class with two string properties named Prop1 and Prop2  and your GetHashCode returns the xor of their hash code. It will work fine for most of the cases except cases where same values are assigned to different properties. It will generate same hash-code i.e. collision in that case as can be seen in the below example . However, using the modified approach as recommenced by Joshua Bloch's in Effective Java which uses prime multiplication and hash chaining provides more unif
Post a Comment
Read more

SQL Performance improvement for User defined table types

Recently, I have dealt with an interesting performance issue with one of my SQL query and thought I will share the experience here. Context: We had a legacy stored procedure responsible for saving large amount of excel row data to our database tables. It was using   User Defined Table Types as one of the parameter to get a list of row data from excel. However, the stored procedure was taking very long time to save the large data set. Root Cause: After quite a bit of investigation using execution plan in SSMS, I was able to narrow down the performance issue to the following: Joining with User defined table type was taking >90 percent of the time A custom hash function which has been used multiple times as a join criteria was also quite expensive to compute. After doing additional research using stack overflow , I was able to figure out that the primary reason for the poor performance doing a  JOIN on Table Valued parameters is that : it does not keep statistics and a
Post a Comment
Read more