Hi,<div><br></div><div>  A stack overflow at startup usually means there was a verification error in one of the methods JITted at startup, the JIT tries to throw an exception, but the exception ctor also contains a verification error, leading to infinite recursion. Try running with </div>
<div>MONO_DEBUG=break-on-unverified </div><div><br></div><div>which will break at the site of the verification error.</div><div><br></div><div>             Zoltan<br><br><div class="gmail_quote">On Fri, Mar 19, 2010 at 1:07 PM, Sanjoy Das <span dir="ltr">&lt;<a href="mailto:sanjoy@playingwithpointers.com">sanjoy@playingwithpointers.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi!<br>
<br>
I&#39;m student who&#39;s getting started with hacking on the mono runtime<br>
(specifically on the SGen Garbage Collector). I was trying to patch up<br>
support for non-aligned nurseries and wrote up some code to generate the<br>
write barrier for the same (mentioned as a FIXME in sgen-gc.c). When I<br>
try to test the code I get a stack overflow error (gdb backtrace<br>
attached). Apparently, for some reason, the control jumps to the<br>
&#39;unverified:&#39; label in &#39;mono_method_to_ir&#39; and the entire thing crashes<br>
due to some memory access violation in a print routine. Since the<br>
backtrace does not show from _where_ the control jumped to &#39;unverified:&#39;<br>
label, I&#39;m pretty much clueless. Manually stepping through the code<br>
would be an option, I guess, but I really wish to avoid it in case<br>
something more streamlined is possible.<br>
<br>
Another thing I am curious about is how to go about testing / debugging<br>
the runtime. My current workflow consists of<br>
<br>
1. Compiling the code (from mono/mono, since that&#39;s faster and I don&#39;t<br>
touch anything outside, thanks to Mark).<br>
2. Run mono/mono/mini/mono with some test image (and remembering to set<br>
MONO_PATH accordingly).<br>
<br>
I initially intended to use some real software like Tomboy to test the<br>
runtime but decided against it because of all the dependencies. To test<br>
the above code, I wrote a toy program which allocates random amounts of<br>
memory. I&#39;ve attached the source.<br>
<br>
Coming to the point, I was wondering if I could get some feedback on the<br>
following areas:<br>
<br>
a. How to go about testing / debugging the runtime? I&#39;ve tried using<br>
valgrind and gdb to test the code, but could not make very good use of<br>
it (mostly because, as I said, I&#39;m clueless about which GOTO is actually<br>
fired). Are there any specific tools I should be aware of?<br>
<br>
b. About the non-aligned nurseries - is *my* code causing problems or is<br>
the support for non-aligned nurseries generally incomplete? If the<br>
latter is true, I would love to get some pointers to where all work is<br>
required to get it working.<br>
<br>
I do understand that, at the moment, robust support for non-aligned<br>
nurseries is probably not required, but I figured it would be a good<br>
learning project.<br>
<font color="#888888"><br>
--<br>
Regards,<br>
<br>
Sanjoy Das<br>
<a href="http://playingwithpointers.com" target="_blank">http://playingwithpointers.com</a><br>
<a href="http://playingwithpointers.com/custom/public_key.txt" target="_blank">http://playingwithpointers.com/custom/public_key.txt</a><br>
</font><br>_______________________________________________<br>
Mono-devel-list mailing list<br>
<a href="mailto:Mono-devel-list@lists.ximian.com">Mono-devel-list@lists.ximian.com</a><br>
<a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a><br>
<br></blockquote></div><br></div>