[Mono-bugs] [Bug 82087][Nor] New - Problem in Hastable when using custom IComparer

bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com
Thu Jul 12 13:55:15 EDT 2007


Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by lluis at ximian.com.

http://bugzilla.ximian.com/show_bug.cgi?id=82087

--- shadow/82087	2007-07-12 13:55:15.000000000 -0400
+++ shadow/82087.tmp.7242	2007-07-12 13:55:15.000000000 -0400
@@ -0,0 +1,30 @@
+Bug#: 82087
+Product: Mono: Class Libraries
+Version: 1.2
+OS: 
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Normal
+Component: CORLIB
+AssignedTo: mono-bugs at ximian.com                            
+ReportedBy: lluis at ximian.com               
+QAContact: mono-bugs at ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: Problem in Hastable when using custom IComparer
+
+Hashtable has a problem that may manifest when using a custom IComparer.
+The problem is that in some cases Hastable may call IComparer.Compare
+(object x, object y), providing an object in x or y which may not be of the
+type expected by the comparer. That's because Hashtable internally uses a
+special key marker object for slots which have been deleted, and doesn't do
+a check before calling the Compare method.
+
+I found this problem when using Gtk.NodeView, which internally uses a
+hashtable to store identifiers. I'm going to attach a simplified example
+that shows how the identifier hashtable may lead to a crash. After 1300
+iterations or so the comparer crashes with an InvalidCastException, because
+one of the provided objects is not an int.


More information about the mono-bugs mailing list