[Gc] Potential bug in dyn_load.c
hans.boehm at hp.com
Mon Aug 30 11:32:54 PDT 2004
Unfortunately, I'm neither an ELF expert, nor the original author of this
piece of code.
I've added a FIXME comment for now, explaining that this code seems
highly dependent on idiosyncrasies of old GNU tool chains. (I'm
pretty sure I used to run this code regularly, so it used to work,
though I can certainly see your argument that that may have involved
If you have a patch for doing this correctly, that would of course
be preferable. Is it even possible? I suspect this was very
Is there a significant danger of this failing only
intermittently? It doesn't sound like it to me.
If so, and if we don't have a patch, I can add a runtime warning
> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com]On Behalf Of Mike Hearn
> Sent: Monday, August 30, 2004 7:22 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] Potential bug in dyn_load.c
> In the course of compiling libgc in unusual ways, I seem to
> have found a
> bug in the GC_register_dynamic_libraries() function. In
> particular when
> dl_iterate_phdrs is not defined (ie on a very old glibc system) the
> codepath taken segfaults because lm->l_addr is NULL.
> I know a bit about ELF and can't really figure this code out.
> GL_FirstDLOpenedLinkMap is looking for the DT_DEBUG header,
> however this
> header is not mandatory. It's present in all gnu toolchain generated
> binaries by co-incidence, so it doesn't seem very safe to me. I'm also
> not sure what it's doing with the result: DT_DEBUG often
> points nowhere,
> and this seems to the problem here as it returns a link map with an
> address of zero which is dereferenced causing a crash.
> I know why dl_iterate_phdrs isn't being used in my particular case and
> will fix it now but I thought you might want a bug report as this
> codepath is unlikely to be used often.
> thanks -mike
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc