[Mono-dev] Non Aligned Nurseries

Sanjoy Das sanjoy at playingwithpointers.com
Fri Mar 19 08:07:13 EDT 2010


Hi!

I'm student who's getting started with hacking on the mono runtime
(specifically on the SGen Garbage Collector). I was trying to patch up
support for non-aligned nurseries and wrote up some code to generate the
write barrier for the same (mentioned as a FIXME in sgen-gc.c). When I
try to test the code I get a stack overflow error (gdb backtrace
attached). Apparently, for some reason, the control jumps to the
'unverified:' label in 'mono_method_to_ir' and the entire thing crashes
due to some memory access violation in a print routine. Since the
backtrace does not show from _where_ the control jumped to 'unverified:'
label, I'm pretty much clueless. Manually stepping through the code
would be an option, I guess, but I really wish to avoid it in case
something more streamlined is possible.

Another thing I am curious about is how to go about testing / debugging
the runtime. My current workflow consists of 

1. Compiling the code (from mono/mono, since that's faster and I don't
touch anything outside, thanks to Mark).
2. Run mono/mono/mini/mono with some test image (and remembering to set
MONO_PATH accordingly).

I initially intended to use some real software like Tomboy to test the
runtime but decided against it because of all the dependencies. To test
the above code, I wrote a toy program which allocates random amounts of
memory. I've attached the source.

Coming to the point, I was wondering if I could get some feedback on the
following areas:

a. How to go about testing / debugging the runtime? I've tried using
valgrind and gdb to test the code, but could not make very good use of
it (mostly because, as I said, I'm clueless about which GOTO is actually
fired). Are there any specific tools I should be aware of?

b. About the non-aligned nurseries - is *my* code causing problems or is
the support for non-aligned nurseries generally incomplete? If the
latter is true, I would love to get some pointers to where all work is
required to get it working.

I do understand that, at the moment, robust support for non-aligned
nurseries is probably not required, but I figured it would be a good
learning project.

-- 
Regards,

Sanjoy Das
http://playingwithpointers.com
http://playingwithpointers.com/custom/public_key.txt
-------------- next part --------------
(gdb) backtrace
#0  _IO_default_xsputn (f=0x7fffff8086d0, data=<value optimized out>, n=24) at genops.c:468
#1  0x00007ffff6d5e526 in _IO_vfprintf_internal (s=0x7fffff8086d0, format=<value optimized out>, 
    ap=0x7fffff808830) at vfprintf.c:1601
#2  0x00007ffff6d7f41a in _IO_vasprintf (result_ptr=0x7fffff808818, format=0x6e001e "%s%s:%s%s (%s)", 
    args=0x7fffff808830) at vasprintf.c:64
#3  0x00007ffff79872e0 in g_vasprintf () from /lib/libglib-2.0.so.0
#4  0x00007ffff7973d80 in g_strdup_vprintf () from /lib/libglib-2.0.so.0
#5  0x00007ffff7973e1d in g_strdup_printf () from /lib/libglib-2.0.so.0
#6  0x00000000005b2b39 in mono_method_full_name (method=0xa36590, signature=1) at debug-helpers.c:788
#7  0x0000000000454c94 in set_exception_type_from_invalid_il (cfg=0x375bad0, method=0xa36590, 
    ip=0xa36616 "\003\002 ") at method-to-ir.c:5010
#8  0x0000000000488d8c in mono_method_to_ir (cfg=0x375bad0, method=0xa36590, start_bblock=0x375c688, 
    end_bblock=0x375c798, return_var=0x0, dont_inline=0x9d8640, inline_args=0x0, inline_offset=0, 
    is_virtual_call=0) at method-to-ir.c:9863
#9  0x0000000000421549 in mini_method_compile (method=0xa36590, opts=51472895, domain=0x9db670, 
    run_cctors=1, compile_aot=0, parts=0) at mini.c:3950
#10 0x0000000000422eb2 in mono_jit_compile_method_inner (method=0xa36590, target_domain=0x9db670, 
    opt=51472895, jit_ex=0x7fffff809db0) at mini.c:4598
#11 0x0000000000423978 in mono_jit_compile_method_with_opt (method=0xa36590, opt=51472895, 
    ex=0x7fffff809db0) at mini.c:4796
#12 0x0000000000423ad3 in mono_jit_compile_method (method=0xa36590) at mini.c:4821
#13 0x0000000000624147 in mono_compile_method (method=0xa36590) at object.c:554
#14 0x00000000004d87f7 in common_call_trampoline (regs=0x7fffff80a1e8, 
    code=0x400121a8 "L\213\064$L\213|$\bH\203\304\030", <incomplete sequence \303>, arg=0xa36590, 
    tramp=0x4001212e "\350\315\376\376\377\004\220e\243", vt=0x0, vtable_slot=0x0, need_rgctx_tramp=0)
    at mini-trampolines.c:491
#15 0x00000000004d8e82 in mono_magic_trampoline (regs=0x7fffff80a1e8, 
    code=0x400121a8 "L\213\064$L\213|$\bH\203\304\030", <incomplete sequence \303>, arg=0xa36590, 
    tramp=0x4001212e "\350\315\376\376\377\004\220e\243") at mini-trampolines.c:613
#16 0x0000000040002168 in ?? ()
#17 0x00007fffff80a5c8 in ?? ()
#18 0x00000000006dff4f in ?? ()
#19 0x00007fffff80a5ac in ?? ()
#20 0x00007fffff80a840 in ?? ()
#21 0x0000000000000000 in ?? ()

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patchfile
Type: text/x-patch
Size: 2249 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20100319/db39ed45/attachment-0003.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Test.cs
Type: text/x-csharp
Size: 290 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20100319/db39ed45/attachment-0004.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20100319/db39ed45/attachment-0005.bin 


More information about the Mono-devel-list mailing list