[Mono-list] RE: GC issue in mono 0.31
Tue, 4 May 2004 14:34:34 -0700
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.
> -----Original Message-----
> From: Nikolai Zhubr [mailto:firstname.lastname@example.org]
> Sent: Tuesday, May 04, 2004 12:53 PM
> To: Boehm, Hans
> Cc: email@example.com; firstname.lastname@example.org
> Subject: Re: GC issue in mono 0.31
> Hello Hans,
> I think my binutils are just of regular Redhat 7.1 linux:
> 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