In article <[email protected]>, Robert Swindells <[email protected]> wrote: > >I wrote: >>Is anyone else getting core dumps when running dynamically linked >>programs ? >> >>An example backtrace for ifconfig is: >> >>#0 0x00007f7ff7c0b79f in memcpy () from /libexec/ld.elf_so >>#1 0x00007f7ff7c04302 in _rtld_do_copy_relocation >(dstobj=dstobj@entry=0x7f7ff7ef9000, rela=<optimized out>, >rela=<optimized out>) at /u1/src/libexec/ld.elf_so/reloc.c:105 >>#2 0x00007f7ff7c04405 in _rtld_do_copy_relocations >(dstobj=0x7f7ff7ef9000) at /u1/src/libexec/ld.elf_so/reloc.c:147 >>#3 0x00007f7ff7c03029 in _rtld (sp=<optimized out>, >relocbase=<optimized out>) at /u1/src/libexec/ld.elf_so/rtld.c:733 >>#4 0x00007f7ff7c007a3 in .rtld_start () from /libexec/ld.elf_so >>#5 0x0000000000000000 in ?? () >> >>This is with sources from today on amd64, including latest binutils. >> >>It looks as if the mapbase and relocbase members of the Obj_Entry struct >>are set to unmapped addresses. > >The symbol that is being processed at the time of the fault is >"_in6addr_any", which is a weak alias to "in6addr_any". > >In an older working copy of ifconfig it has: > >Disassembly of section .bss: > >0000000000618300 <_in6addr_any>: > ... > >The non-working latest copy has: > >Disassembly of section .data.rel.ro: > >0000000000615e40 <_in6addr_any>: > ...
I am unable to reproduce this... What are the addresses is it faulting at? christos
