[Mono-bugs] [Bug 62892][Nor] New - Double free/abort trap on nunit-console test failure.

[bugzilla-daemon@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 mass@akuma.org.

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

--- shadow/62892	2004-08-11 17:55:37.000000000 -0400
+++ shadow/62892.tmp.27122	2004-08-11 17:55:37.000000000 -0400
@@ -0,0 +1,55 @@
+Bug#: 62892
+Product: Mono: Runtime
+Version: unspecified
+OS: 
+OS Details: Mac OS X 10.4 tiger preview seed update 1
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Normal
+Component: misc
+AssignedTo: mono-bugs@ximian.com                            
+ReportedBy: mass@akuma.org               
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: Double free/abort trap on nunit-console test failure.
+
+Local build /Library/Frameworks/Mono.framework/Versions/20040810T13-CVS/
+
+Simple test case;
+
+compile the attached file into a library, referencing nunit.framework, i.e.
+mcs /t:library a.cs /r:nunit.framework
+
+run file through the nunit console, telling mono to include debugging
+information, i.e.
+mono --debug nunit-console.exe a.dll
+
+on cleanup, there will be a double free().
+
+I run with
+MallocBadFreeAbort=1 mono --debug nunit-console.exe a.dll /wait
+
+after the test failure (and before the double dealloc) it will pause,
+letting you attach gdb
+
+The last few frames of the stack trace looks like:
+#0  0x900421ec in kill ()
+#1  0x9009c55c in abort ()
+#2  0x9000137c in free ()
+#3  0x00285948 in mono_debug_close_image (handle=0x2d2b600) at mono-debug.c:141
+#4  0x006146ac in g_hash_nodes_destroy (hash_node=0x2112e24,
+key_destroy_func=0, value_destroy_func=0x28591c
+<mono_debug_close_image>) at ghash.c:744
+#5  0x006132c0 in g_hash_table_destroy (hash_table=0x1b312d0) at ghash.c:178
+#6  0x00285814 in mono_debug_cleanup () at mono-debug.c:98
+#7  0x0021b710 in mini_cleanup (domain=0x54f18) at mini.c:8397
+
+and the handle.image.name field looks corrupted. strangely, it doesn't
+look scribbled over if I turn on malloc scribbling, thats the
+worrisome part.
+
+Update: kangaroo ran under panther, on his system it still fails, but it aborts before hitting the 
+nunit wait.