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

[Boehm, Hans]

I assume nothing is prelinked?  I don't think that was even an option
on RedHat 7.1.

It would be helpful to set a breakpoint in GC_add_roots_inner, and
verify that it's actually being called with (DATAEND, which is
defined to be) _end as its middle argument.

It looks like both mono and libmono define _end.  By the normal ELF
default symbol lookup rules, I believe libmono references to _end should see the
definition in the main program.  If this is indeed not happening, and if the
libmono developers aren't aware of other relevant issues, I would ask
on a binutils mailing list for ideas.

Hans

> -----Original Message-----
> From: Nikolai Zhubr [mailto:s001@hotbox.ru]
> Sent: Tuesday, May 04, 2004 12:53 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,
> I think my binutils are just of regular Redhat 7.1 linux:
> binutils-2.10.91.0.2-3
> GNU ld 2.10.91
> Copyright 2001 Free Software Foundation, Inc.
> I've just checked, there are no occurencies of "Bsymbolic"
> anywhere within mono build tree.
> The output of nm is attached.
> -- 
> Best regards,
>  Nikolai Zhubr
> Tuesday, 04 May, 2004, 1:41:32, you wrote:
> > 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
>