Bug 66473 - seg fault with Boehm GC in RH 7.3
seg fault with Boehm GC in RH 7.3
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
7.3
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-06-10 17:55 EDT by Need Real Name
Modified: 2016-11-24 09:49 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-06-11 04:31:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2002-06-10 17:55:19 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126
Netscape6/6.2.1

Description of problem:
The GC garbage collector, http://www.hpl.hp.com/personal/Hans_Boehm/gc/, worked
fine on RH 7.2, but on RH 7.3 it segfaults while processing the ELF header of
the executable when it starts up.

It segfaults in GC_register_dynamic_libraries(), where it's reading the struct
link_map entry for "/lib/i686/libc.so.6".

487             e = (ElfW(Ehdr) *) lm->l_addr;
488             p = ((ElfW(Phdr) *)(((char *)(e)) + e->e_phoff));

It dies at the e->e_phoff part because e is NULL.

I've stepped through this with gdb, and it reports that the l_addr field of the
link_map entry is NULL instead of the expected value, e.g. 0x42000000 or some
such.  I walked through the list of link_map entries, and all the other mapped
shared objects have reasonable values for l_addr.

I suppose this could be a GC bug, but since the value it is dying on is NULL and
seems like it shouldn't be, I'm filing a report here.

I don't understand glibc or ELF enough to do more to fix the problem myself, but
will be happy to gather more information for you if you tell me what you want.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Install GC 6.0
2. Create and link a program which calls GC_malloc(), e.g.:

#include <gc.h>

int main() {
  char *a;

  a = GC_malloc(100);
  return (0);
}


3. run the program
	

Actual Results:  The program cores as described above.

Expected Results:  The program works successfully allocates 100 bytes of memory.

Additional info:
Comment 1 Need Real Name 2002-06-11 04:31:16 EDT
I tried this with GC 6.1alpha4 and it doesn't core.  I diffed the old dyn_load.c
and the newer one and it seems like the method of walking ELF headers was
changed if the GCC library version is >= 2.2.4.

Sorry about the false alarm.
Comment 2 Jakub Jelinek 2002-06-11 05:28:40 EDT
Yeah, I've changed it because the assumption that the ELF headers are at
lm->l_addr is broken. l_addr is the difference between actual address the
library was mmaped at and the virtual address of first PT_LOAD segment in it
stored in the library. If the first VA is 0, then ELF headers can be found
at lm->l_addr, but if it is not 0 (such as happens with prelink(8) or on MIPS,
or when the library is linked with a different linker script), then this results
in core dump.

Note You need to log in before you can comment on or make changes to this bug.