Bug 3852 - ld segfaults in mips_elf_create_dynamic_relocation
Summary: ld segfaults in mips_elf_create_dynamic_relocation
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.18
: P2 normal
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-01-10 19:27 UTC by Khem Raj
Modified: 2007-02-01 09:02 UTC (History)
1 user (show)

See Also:
Host: i386-redhat-linux
Target: mips-*-linux
Build: i386-redhat-linux
Last reconfirmed:


Attachments
testcase (412.19 KB, application/x-gzip)
2007-01-10 19:27 UTC, Khem Raj
Details
Zero all fields in the elf_link hash table when it is created (573 bytes, patch)
2007-01-31 16:13 UTC, Nick Clifton
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Khem Raj 2007-01-10 19:27:23 UTC
mips ld is segfaulting with the attached case from glibc. This was working ok
with  binutils from December 12 2006 but not with december 18th some checkin
between these two dates broke it.
Comment 1 Khem Raj 2007-01-10 19:27:56 UTC
Created attachment 1483 [details]
testcase
Comment 2 Nick Clifton 2007-01-11 16:36:47 UTC
Hi Khem,

  Please could you try this test again using the latest binutils sources ?

  I tried running the test today and the linker did not seg fault...

Cheers
  Nick
Comment 3 Khem Raj 2007-01-12 20:33:27 UTC
hmmm I could reproduce it with todays snapshot too.

GNU ld version 2.17.50 20070112

I am using FC6 to build ld but I could see it happening on centos3 machine as well so probably not a 
host issue.

I configured binutils as 

./configure --target=mips-linux

Comment 4 Nick Clifton 2007-01-19 15:16:24 UTC
Subject: Re:  ld segfaults in mips_elf_create_dynamic_relocation

Hi Raj,

> hmmm I could reproduce it with todays snapshot too.

> I configured binutils as 
> ./configure --target=mips-linux

Sorry, I still cannot reproduce the problem, even using that exact 
configuration string.

Can you do some more digging and find out where the seg-fault is 
occurring ?   Maybe you could also track down the patch that was applied 
between Dec 12 and Dec 18 that introduced the seg fault ?

Cheers
   Nick


Comment 5 Khem Raj 2007-01-24 23:22:35 UTC
OK I found something interesting its with the ld names

if I use ld-new it works fine but we rename it to mips2_fp_be-ld and it
segfaulted. However then I played with the ld binary name size I started adding
numeral after ld to see how long before it segfaults.

it worked till ld012345678

but 

ld0123456789 segfaulted. 

So it seems it has to do with the length of the binary name.
Comment 6 Nick Clifton 2007-01-25 16:31:57 UTC
Subject: Re:  ld segfaults in mips_elf_create_dynamic_relocation

Hi Raj,

> OK I found something interesting its with the ld names
> 
> if I use ld-new it works fine but we rename it to mips2_fp_be-ld and it
> segfaulted.

It must be a memory corruption bug of some form.  Have you tried using 
valgrind to track down the problem ?

Cheers
   Nick

Comment 7 Khem Raj 2007-01-25 18:04:15 UTC
(In reply to comment #6)
> Subject: Re:  ld segfaults in mips_elf_create_dynamic_relocation
> 
> Hi Raj,
> 
> > OK I found something interesting its with the ld names
> > 
> > if I use ld-new it works fine but we rename it to mips2_fp_be-ld and it
> > segfaulted.
> 
> It must be a memory corruption bug of some form.  Have you tried using 
> valgrind to track down the problem ?
> 
> Cheers
>    Nick
> 
> 

Valgrind gives identical results in both cases.
Comment 8 Khem Raj 2007-01-26 21:45:18 UTC
Here is some more information.

Steps to reproduce 

../binutils/configure --host=i686-pc-linux-gnu
--target=mips-montavista-linux-gnu
--prefix=/opt/montavista/foundation/devkit/mips/mips2_fp_be

make

the copy the ld-new to the same directory where the test case is and invoke the
ld-new 

./ld-new -v -shared -o ld.so -z relro -z defs librtld.os --version-script=ld.map
-soname=ld.so.1 -T ld.so.lds

GNU ld version 2.17.50 20070126
Segmentation fault (core dumped)


if you invoke ld-new from same directory where it was built it will work.

Secondly if the configure command is now altered (say dropping mips2_fp_be from
--prefix)

../binutils/configure --host=i686-pc-linux-gnu
--target=mips-montavista-linux-gnu --prefix=/opt/montavista/foundation/devkit/mips

Then it works everywhere normal.

I could reproduce it with ld dating back from Dec 02,2006 till latest from cvs

from valgrind -v everything looks same except one place

ok ld
--11498-- scheduler: 8,908,114 jumps (bb entries).

segfaulting ld

--11519-- scheduler: 8,908,237 jumps (bb entries).



Comment 9 Nick Clifton 2007-01-31 16:13:03 UTC
Created attachment 1528 [details]
Zero all fields in the elf_link hash table when it is created
Comment 10 Nick Clifton 2007-01-31 16:15:11 UTC
Hi Khem,

  Good news - I can now reproduce this bug and I think that I have tracked it
down.  It appears to be an uninitialized memory bug.  The text_index_section
field in the elf_link_hash_table structure is not being initialized when the
structure is created, leading to all kinds of problems.

  Please could you try out the uploaded patch which should resolve this issue ?

Cheers
  Nick
Comment 11 Khem Raj 2007-01-31 20:03:21 UTC
Thanks a lot Nick. I tested this patch and it fixes my problem. 
Comment 12 Khem Raj 2007-01-31 20:04:20 UTC
Too quick to resolve fixed. I think it should change status after the patch is
accepted/committed to repository.
Comment 13 Nick Clifton 2007-02-01 09:02:30 UTC
Patch committed with this ChangeLog entry.

bfd/ChangeLog
2007-02-01  Nick Clifton  <nickc@redhat.com>

	PR ld/3852
	* elf.c (_bfd_elf_link_hash_table_init): Initialize all the fields
	in the elf_link_hash_table structure.