Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: rtld problem



In article <x7y3hkurvn.fsf%ren.fdy2.co.uk@localhost>,
Robert Swindells  <rjs%fdy2.co.uk@localhost> wrote:
>
>christos%astron.com@localhost (Christos Zoulas) wrote:
>>In article <x736ztwugb.fsf%ren.fdy2.co.uk@localhost>,
>>Robert Swindells  <rjs%fdy2.co.uk@localhost> 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?
>
>This seems to be caused by differences in build options, I was building
>with:
>
>USE_SSP=no
>USE_FORT=no
>MKPIE=no
>
>Without them I get:
>
>Disassembly of section .got:
>
>0000000000219fa8 <.got>:
>        ...
>                        219fc0: R_X86_64_GLOB_DAT       in6addr_any
>
>Which is the same as in the latest snapshot on nyftp.
>
>I think the faulting address is the destination of the memcpy(), it
>doesn't look to be mapped writable.

Yes, that copy relocation is bad..

#diff good bad
9,11c9,11
< 0000000000618320 R_X86_64_COPY     _in6addr_any
< 0000000000618330 R_X86_64_COPY     _ctype_tab_
< 0000000000618338 R_X86_64_COPY     optarg
---
> 0000000000615e40 R_X86_64_COPY     _in6addr_any
            ^^^^^^
> 0000000000618320 R_X86_64_COPY     _ctype_tab_
> 0000000000618328 R_X86_64_COPY     optarg




Home | Main Index | Thread Index | Old Index