Bug 9590 - sgen crash on weak reference stress test
Summary: sgen crash on weak reference stress test
Alias: None
Product: Runtime
Classification: Mono
Component: GC ()
Version: unspecified
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2013-01-15 18:41 UTC by Zoltan Varga
Modified: 2013-01-17 14:31 UTC (History)
4 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Zoltan Varga 2013-01-15 18:41:14 UTC
using System;
using System.Threading;
using System.Collections.Generic;

public class Tests
	public static void Main (String[] args) {
		var t = new Thread [10];
		int fcount = 0;
		for (int i = 0; i < 10; ++i) {
			t [i] = new Thread (delegate () {
					for (int j = 0; j < 1000; ++j) {
						var w = new WeakReference (new object ());
					Interlocked.Increment (ref fcount);
		for (int i = 0; i < 10; ++i)
			t [i].Start ();
		while (true) {
			if (fcount == 10)
			GC.Collect ();
Run it like this:
while true; do mono-sgen bug.exe || break; done

The crash is usually:
#4  0x0000000103c47620 in sgen_safe_object_get_size (obj=0xfffffffffffffffc) at sgen-gc.h:833
#5  0x0000000103c47507 in major_is_object_live (obj=0xfffffffffffffffc <Address 0xfffffffffffffffc out of bounds>) at sgen-marksweep.c:841
#6  0x0000000103c9d6f5 in sgen_null_link_in_range (start=0x0, end=0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>, generation=0, before_finalization=0, ctx={scan_func = 0x103c49450 <major_scan_object>, copy_func = 0x103c49420 <major_copy_or_mark_object_canonical>, queue = 0x103e65500}) at sgen-fin-weak-hash.c:456
#7  0x0000000103c37223 in finish_gray_stack (start_addr=0x0, end_addr=0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>, generation=1, queue=0x103e65500) at sgen-gc.c:1976
#8  0x0000000103c3acd3 in major_finish_collection (reason=0x103dc3715 "user request", old_next_pin_slot=95, scan_mod_union=0) at sgen-gc.c:3052
Comment 1 Rodrigo Kumpera 2013-01-16 16:39:23 UTC
Working on it.

The backtrace is super suspicious:

GC thread:

#5  <signal handler called>
#6  0x0036f0df in sgen_safe_object_get_size (obj=0xfffffffc) at sgen-gc.h:833
#7  0x0036efe0 in major_is_object_live (obj=0xfffffffc <Address 0xfffffffc out of bounds>) at sgen-marksweep.c:841
#8  0x003b243c in sgen_null_link_in_range (start=0x0, end=0xffffffff <Address 0xffffffff out of bounds>, generation=0, before_finalization=0, ctx={scan_func = 0x370940 <major_scan_object>, copy_func = 0x370900 <major_copy_or_mark_object_canonical>, queue = 0x4f56c8}) at sgen-fin-weak-hash.c:456

User thread:
#0  0x003b1dd1 in add_stage_entry (num_entries=0, next_entry=0x78c4c630, entries=0x0, obj=0x0, user_data=0x0) at sgen-fin-weak-hash.c:285
#1  0x003b2bc6 in sgen_register_disappearing_link (obj=0x0, link=0x78c4c630, track=0, in_gc=0) at sgen-fin-weak-hash.c:613
#2  0x00368eb4 in mono_gc_weak_link_remove (link_addr=0x78c4c630, track=0) at sgen-gc.c:4616
#3  0x0031ceef in mono_gchandle_free (gchandle=70753) at gc.c:912
#4  0x0031bda7 in ves_icall_System_GCHandle_FreeHandle (handle=70753) at gc.c:556
Comment 2 Rodrigo Kumpera 2013-01-17 14:31:16 UTC
Fixed on master. Will be on 3.0.4.