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:
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.
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.