[Mono-list] RE: GC issue in mono 0.31

[Boehm, Hans]

This means that the collector tried to trace, i.e. look for pointer in,
a memory range that was not in fact mapped.  The interesting values
to look at are local variables current_p and limit, as well as the output
of GC_dump() and a copy of /proc/<pid>/maps.

Possible causes are:

1) The collector is confused about the location of the cold end of
the main stack.  You might check that GC_stackbottom looks reasonable.

2) The collector is confused about the location of a data segment.

3) The collector was mistakenly not configured for thread support.

I suspect the collector hasn't been as heavily tested with 2.6 kernels
and NPTL as it should have been.  I'm also trying to so some of that
as we speak.

Does gctest ("make check") in the gc directory work?  (I assume that
should still work with the Mono version of the collector.)

Once you're sure that this is not a Mono-specific issue, it's good to
copy the gc@linux.hpl.hp.com mailing list.

Hans

> -----Original Message-----
> From: Nikolai Zhubr [mailto:s001@hotbox.ru]
> Sent: Sunday, May 02, 2004 3:54 PM
> To: boehm@acm.org; mono-gc-list@lists.ximian.com; mono-list@ximian.com
> Subject: GC issue in mono 0.31
> 
> 
> Hello,
> I have a problem running mono 0.31 - it segfaults almost
> immediately in GC startup code, as far as I can see. Here
> is the call sequence:
> GC_malloc ->
>  GC_generic_malloc_inner ->
>   GC_init_inner ->
>    GC_try_to_collect_inner ->
>     GC_stopped_mark ->
>      GC_mark_some ->
>       GC_mark_from ->
>       mark.c:line 769: defered = *limit; <<<=== segfault.
> Note: GC_mark_from() executes successfully some few times,
> then segfaults. The assembly file specified as an argument
> doesn't seem to be relevant. Starting with no arguments
> displays help screen normally.
> I'm using 686 linux 2.6.5, gcc 3.3.1. Let me know if I should
> provide more details.
> Thank you.
> (I'm not on ML, please CC me so I can get reply)
> -- 
> Best regards,
>  Nikolai Zhubr
> 
>