Bug 17590 - * Assertion at sgen-alloc.c:425, condition `*p == NULL' not met
Summary: * Assertion at sgen-alloc.c:425, condition `*p == NULL' not met
Status: RESOLVED FIXED
Alias: None
Product: Runtime
Classification: Mono
Component: GC ()
Version: unspecified
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Rodrigo Kumpera
URL:
Depends on:
Blocks:
 
Reported: 2014-02-04 06:41 UTC by Marek Safar
Modified: 2014-02-10 15:47 UTC (History)
3 users (show)

Tags:
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:
Status:
RESOLVED FIXED

Description Marek Safar 2014-02-04 06:41:55 UTC
using System;

class X
{
	public static void Main ()
	{
		"abcd".PadRight(int.MaxValue);
	}
}
Comment 1 Marek Safar 2014-02-04 06:42:39 UTC
Requires mono master

* Assertion at sgen-alloc.c:425, condition `*p == NULL' not met

Stacktrace:


Native stacktrace:

	0   mono                                0x00176348 mono_handle_native_sigsegv + 456
	1   mono                                0x0022cf3b sigabrt_signal_handler + 171
	2   libsystem_platform.dylib            0x933c8deb _sigtramp + 43
	3   ???                                 0xffffffff 0x0 + 4294967295
	4   libsystem_c.dylib                   0x9a09a340 abort + 155
	5   mono                                0x00467fa2 monoeg_g_logv + 322
	6   mono                                0x00468047 monoeg_assertion_message + 71
	7   mono                                0x003f4fa6 mono_gc_try_alloc_obj_nolock + 1254
	8   mono                                0x003f49a5 mono_gc_alloc_obj + 405
	9   mono                                0x0037b18e mono_object_allocate_spec + 46
	10  mono                                0x0037b0c7 mono_object_new_alloc_specific + 103
	11  mono                                0x0037afd8 mono_object_new_specific + 456
	12  mono                                0x0037770b mono_object_new + 75
	13  mono                                0x0026f336 mono_exception_from_token + 70
	14  mono                                0x00116729 mono_create_corlib_exception_0 + 41
	15  ???                                 0x0072114c 0x0 + 7475532
	16  ???                                 0x00720fa0 0x0 + 7475104
	17  ???                                 0x00720ee0 0x0 + 7474912
	18  ???                                 0x00720f76 0x0 + 7475062
	19  mono                                0x00064746 mono_jit_runtime_invoke + 2342
	20  mono                                0x0036cc60 mono_runtime_invoke + 208
	21  mono                                0x00378def mono_runtime_exec_main + 847
	22  mono                                0x00378a97 mono_runtime_run_main + 1079
	23  mono                                0x0012de0e mono_jit_exec + 286
	24  mono                                0x00131d37 main_thread_handler + 647
	25  mono                                0x001306a0 mono_main + 8960
	26  mono                                0x0004e6c8 mono_main_with_options + 1016
	27  mono                                0x0004e2c0 main + 64
	28  libdyld.dylib                       0x9b11670d start + 1
	29  ???                                 0x00000002 0x0 + 2
Comment 2 Mark Probst 2014-02-05 20:23:20 UTC
We don't check on overflow when calculating the size of the string object to be allocated, so for int.MaxValue we actually end up with a string of length 0.  The unsafe code in PadRight then proceeds to write past the end of that object, and we end up crashing.

This needs to be fixed in create_allocator() in sgen-alloc.c.  I'll get on it tomorrow.

Thanks!
Comment 3 Mark Probst 2014-02-10 15:47:59 UTC
Fixed in d77573cead75c79c1268c96031b15700a66c06e3.