[Mono-bugs] [Bug 78125][Nor] Changed - runtime segfault in program using C5.HashDictionary

[bugzilla-daemon at bugzilla.ximian.com]

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 bcs26 at cornell.edu.

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

--- shadow/78125	2006-04-21 18:59:54.000000000 -0400
+++ shadow/78125.tmp.21502	2006-04-23 21:01:37.000000000 -0400
@@ -1,13 +1,13 @@
 Bug#: 78125
 Product: Mono: Runtime
 Version: 1.1
 OS: unknown
 OS Details: 
-Status: RESOLVED   
-Resolution: FIXED
+Status: REOPENED   
+Resolution: 
 Severity: Unknown
 Priority: Normal
 Component: misc
 AssignedTo: mono-bugs at ximian.com                            
 ReportedBy: bcs26 at cornell.edu               
 QAContact: mono-bugs at ximian.com
@@ -111,6 +111,86 @@
 ------- Additional Comments From bcs26 at cornell.edu  2006-04-21 18:59 -------
 Can't reproduce the crash in mono-1.1.15. Since it was always
 nondeterministic, the bug may be merely hidden; but the original
 application now runs successfully using C5.HashDictionary, so I'm
 closing the bug.
 
+
+------- Additional Comments From bcs26 at cornell.edu  2006-04-23 21:01 -------
+Ok, I think I was prematurely optimistic in closing this bug.
+
+If I run the test program above (HashCrash.cs) normally (using just
+"mono"), with mono-1.1.15, it terminates successfully. If I run it
+under "mono --debug --trace", however,  it terminates with the
+following exception:
+
+"
+Unhandled Exception: System.NullReferenceException: Object reference
+not set to an instance of an object
+in <0x00046>
+C5.KeyValuePairEqualityComparer`2[System.Object,System.Object]:GetHashCode
+(KeyValuePair`2 )
+in <0x00063>
+C5.HashSet`1[C5.KeyValuePair`2[System.Object,System.Object]]:gethashcode
+(KeyValuePair`2 )
+in <0x000d9>
+C5.HashSet`1[C5.KeyValuePair`2[System.Object,System.Object]]:searchoradd
+(C5.KeyValuePair`2 , Boolean , Boolean , Boolean )
+in <0x0005b>
+C5.HashSet`1[C5.KeyValuePair`2[System.Object,System.Object]]:UpdateOrAdd
+(KeyValuePair`2 )
+in <0x0008a> C5.DictionaryBase`2[System.Object,System.Object]:set_Item
+(System.Object , System.Object )
+in <0x0008a> Foo:.ctor ()
+in <0x0004e> HashCrash:Main (System.String[] args)
+"
+
+A different test case, virtually identical but using SCG.Dictionary
+instead of C5.HashDictionary, shows the same behavior. If that test
+case is executed under gdb, it terminates with a segfault:
+
+"
+. . . LEAVE: System.Collections.Generic.Dictionary`2:.ctor ()
+. . . ENTER: (wrapper managed-to-native)
+System.Object:__icall_wrapper_mono_object_new_ptrfree_box
+(intptr)(0x730bc0, )
+. . . LEAVE: (wrapper managed-to-native)
+System.Object:__icall_wrapper_mono_object_new_ptrfree_box
+(intptr)[INT32:0x2aaaaab4cfc0:0]
+. . . ENTER: (wrapper managed-to-native)
+System.Object:__icall_wrapper_mono_object_new_ptrfree (intptr)(0x6c25e8, )
+. . . LEAVE: (wrapper managed-to-native)
+System.Object:__icall_wrapper_mono_object_new_ptrfree
+(intptr)[System.Object:0x2aaaaab2cfc0]
+. . . ENTER: System.Object:.ctor ()(this:0x2aaaaab2cfc0[System.Object
+MonoCrash.exe], )
+. . . LEAVE: System.Object:.ctor ()
+. . . ENTER: System.Collections.Generic.Dictionary`2:set_Item
+(object,object)(this:0x2aaaaab4efc0[System.Collections.Generic.Dictionary`2
+MonoCrash.exe], [INT32:0x2aaaaab4cfc0:0],
+[System.Object:0x2aaaaab2cfc0], )
+. . . . ENTER: System.Collections.Generic.Dictionary`2:GetPrev
+(object,int&)(this:0x2aaaaab4efc0[System.Collections.Generic.Dictionary`2
+MonoCrash.exe], [INT32:0x2aaaaab4cfc0:0], [BYREF:0x7fffffb97b44], )
+. . . . . ENTER: System.Collections.Generic.Dictionary`2:DoHash
+(object)(this:0x2aaaaab4efc0[System.Collections.Generic.Dictionary`2
+MonoCrash.exe], [INT32:0x2aaaaab4cfc0:0], )
+
+Program received signal SIGSEGV, Segmentation fault.
+[Switching to Thread 46912509287200 (LWP 28340)]
+0x000000004001b728 in ?? ()
+(gdb)
+"
+
+The test case attached (HashCrash.cs) also generates a SIGSEGV when
+run under gdb.
+
+Furthermore, the larger application that originally uncovered this bug
+is once again crashing with a segfault, even when _not_ run under
+--trace, which suggests a real runtime issue rather than a bug in
+--trace. I haven't yet been able to distill that application into a
+small test case that crashes without --trace.
+
+My guess is that 1.1.15 changed the way in which the bug from 1.1.13.2
+was being exhibited, but that the underlying bug hasn't been fixed.
+Bug #77888 looks potentially related.
+