---- Reported by joe@otee.dk 2004-11-27 21:50:08 MST ----

Running the following c sharp application, i get a crash inside:
Thread 2 Crashed:
0   libSystem.B.dylib   	0x9000147c szone_free + 0x3dc
1   libSystem.B.dylib   	0x9000879c szone_realloc + 0x8bc
2   libSystem.B.dylib   	0x9000a96c malloc_zone_realloc + 0x6c
3   libSystem.B.dylib   	0x90008a1c realloc + 0xfc
4   libglib-2.0.0.dylib 	0x0014a57c g_realloc + 0x40 (gmem.c:170)
5   libmono.0.dylib     	0x00447564 mono_arch_output_basic_block + 0xac (mini-ppc.c:2277)
6   libmono.0.dylib     	0x0043183c mono_codegen + 0xd0 (mini.c:7318)
7   libmono.0.dylib     	0x00432454 mini_method_compile + 0x400 (mini.c:7795)
8   libmono.0.dylib     	0x00432a50 mono_jit_compile_method_inner + 0x228 (mini.c:7947)
9   libmono.0.dylib     	0x0044e860 ppc_magic_trampoline + 0x28 (tramp-ppc.c:108)
10  <<00000000>> 	0x0300eb14 0 + 0x300eb14
11  <<00000000>> 	0x00032c6c 0 + 0x32c6c
12  <<00000000>> 	0x00032890 0 + 0x32890
13  libmono.0.dylib     	0x004770f4 mono_runtime_exec_main + 0x144 (object.c:1576)
14  libmono.0.dylib     	0x00476cbc mono_runtime_run_main + 0x224 (object.c:1429)
15  libmono.0.dylib     	0x00498314 start_wrapper + 0xb4 (threads.c:292)
16  libmono.0.dylib     	0x004df7b8 timed_thread_start_routine + 0xe4 (timed-thread.c:135)
17  libSystem.B.dylib   	0x900246e8 _pthread_body + 0x28

Malloc debug says:
malloc[29984]: error for object 0xc43b30: Incorrect checksum for freed object - object was 
probably modified after being freed; break at szone_error

This happens on mac

---

using System;

public class Test
{
	static void Main ()
	{
		Matrix4x4 m = TestPassing (Matrix4x4.identity, Matrix4x4.identity, 
Matrix4x4.identity);
		Console.WriteLine ("Done!");
	}
	
	static Matrix4x4 TestPassing (Matrix4x4 a, Matrix4x4 b, Matrix4x4 c)
	{
		return Matrix4x4.identity;
	}
}

public struct Matrix4x4
{
	float m00, m10, m20, m30;
    float m01, m11, m21, m31;
 	float m02, m12, m22, m32;
    float m03, m13, m23, m33;

	static public Matrix4x4 identity
	{
		get
		{
			Matrix4x4 m;
			m.m00 = 1F; m.m01 = 0F; m.m02 = 0F; m.m03 = 0F;
			m.m10 = 0F; m.m11 = 1F; m.m12 = 0F; m.m13 = 0F;
			m.m20 = 0F; m.m21 = 0F; m.m22 = 1F; m.m23 = 0F;
			m.m30 = 0F; m.m31 = 0F; m.m32 = 0F; m.m33 = 1F;
			return m;
		}
	}
}

----



---- Additional Comments From grompf@sublimeintervention.com 2004-11-28 18:13:54 MST ----

lupus,

  This is a "too small prolog" bug again; probably because of the number of hits into the 
struct?  the g_assert is getting hit with code_len 384 code_size 316.  We could realloc up 
for structs; but thats "expensive"; how would you like to see this fixed?

-kangaroo




---- Additional Comments From grompf@sublimeintervention.com 2004-12-02 17:45:06 MST ----

Created an attachment (id=167086)
patch




---- Additional Comments From grompf@sublimeintervention.com 2004-12-02 17:45:39 MST ----

lupus,

  Attached above is a patch to realloc for the memcpy;  I'm not sure this is ideal due to 
realloc cost; but it does solve the issue.  Thoughts?

-kangaroo




---- Additional Comments From lupus@ximian.com 2004-12-07 06:31:24 MST ----

As we discussed on irc, the correct fix is to inline a memcpy
loop, otherwise the prolog would get arbitrarily large.
I implemented this on svn, now.
Thanks for tracking down the issue.

Imported an attachment (id=167086)

Unknown bug field "cf_op_sys_details" encountered while moving bug
   <cf_op_sys_details>Mac os x 10.3.5 mono 1.1.2 and 1.0.2</cf_op_sys_details>
Unknown operating system unknown. Setting to default OS "Other".