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

[Boehm, Hans]

The problem is pretty clear:  The GC is treating the region
between __data_start (0x80497b0) and the end of the libmono data segment
(0x401851a0) as a single traceable data region.  That probably means
_end is somehow defined by the linker to be the end of the libmono
data segment instead of the end of the main data segment.  This
is not how Linux linkers are supposed to behave, though I've
seen similar behavior on other operating systems.  (This assumes that
libmono doesn't use some other mechanism for setting DATAEND.)

If your binutils and linker script came from a standard Linux distribution,
it would be nice to track down how this happened.  If not, that's almost
certainly the source of the problem.

Another possible cause of the problem might be if the gc is linked into
libmono, and that's linked with -Bsymbolic.  (That's probably
not an unreasonable thing to do.  If so, there's probably a way to
work around this.)

The output of nm on the main executable and libmono might be useful
in tracking this down further.

Hans

> -----Original Message-----
> From: Nikolai Zhubr [mailto:s001@hotbox.ru]
> Sent: Monday, May 03, 2004 2:09 PM
> To: Boehm, Hans
> Cc: mono-gc-list@lists.ximian.com; mono-list@ximian.com
> Subject: Re: GC issue in mono 0.31
> 
> 
> Hello Hans,
> It looks like mono GC version doesn't have gctest and does
> nothing for make check. I suppose I'll therefore need to
> download full version first.
> Meanwhile, I've added more debugging prints now so all
> variables you mentioned are displayed just before segv.
> This output + /proc/<mono pid>/maps is attached here.
> I'd also note that NPTL is not present on this box, AFAIK.
> Well, the base system is pretty old, basically RedHat 7.1
> with only some specific packages updated, those which I was
> actually interested in.
> -- 
> Best regards,
>  Nikolai Zhubr
> Monday, 03 May, 2004, 22:18:09, you wrote:
> > 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
>