bug-binutils
[Top][All Lists]
Advanced

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

[Bug ld/23470] New: ld.bfd occasionally segfaults after running out of m


From: awilfox at adelielinux dot org
Subject: [Bug ld/23470] New: ld.bfd occasionally segfaults after running out of memory on 32-bit x86
Date: Tue, 31 Jul 2018 18:55:53 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=23470

            Bug ID: 23470
           Summary: ld.bfd occasionally segfaults after running out of
                    memory on 32-bit x86
           Product: binutils
           Version: 2.30
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: awilfox at adelielinux dot org
  Target Milestone: ---
              Host: i?86-*-*-*

Environment: binutils 2.30 on i586-foxkit-linux-musl (kernel 4.14.56, musl
1.1.19)

While doing final linking for Qt WebKit, ld (without --no-keep-memory) will hit
the memory ceiling of 4 GB on 32-bit x86.

Most of the experimental runs I did just ended with "Memory exhausted", but the
reason I did more than one run in the first place was because the first failure
was a segmentation fault.  In two of five runs, I was able to reproduce it:

Core was generated by
`/usr/lib/gcc/i586-foxkit-linux-musl/6.4.0/../../../../i586-foxkit-linux-musl/bi'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0xf7dd7086 in assign_file_positions_except_relocs (link_info=<optimized
out>, abfd=<optimized out>) at elf.c:6124
6124              && tdata->phdr[0].p_type == PT_PHDR
(gdb) bt
#0  0xf7dd7086 in assign_file_positions_except_relocs (link_info=<optimized
out>, abfd=<optimized out>) at elf.c:6124
#1  _bfd_elf_compute_section_file_positions (abfd=<optimized out>,
address@hidden, link_info=<optimized out>, address@hidden)
at elf.c:4258
#2  0xf7df593e in bfd_elf_final_link (abfd=<optimized out>, info=<optimized
out>) at elflink.c:11779
#3  0x56651352 in ?? ()
#4  0x56636e42 in ?? ()
#5  0xf7ed5438 in __libc_start_main (main=0x56636740, argc=152,
argv=0xffacad34) at src/env/__libc_start_main.c:74
#6  0x5663754a in ?? ()
#7  0x566374f4 in ?? ()


Everything is built with -g, so I am not sure why some frames don't have
symbols.  Additionally, tdata is unfortunately optimised out.


   0xf7dd707d <+11165>: mov    -0xf0(%ebp),%eax
   0xf7dd7083 <+11171>: mov    0x50(%eax),%eax
=> 0xf7dd7086 <+11174>: cmpl   $0x6,(%eax)
   0xf7dd7089 <+11177>: je     0xf7dd7c5e
<_bfd_elf_compute_section_file_positions+14206>
(gdb) info registers
eax            0x0      0
ecx            0x0      0
edx            0x0      0
ebx            0xf7eaa620       -135616992
esp            0xffaca890       0xffaca890
ebp            0xffaca9b8       0xffaca9b8
esi            0xf7ea7240       -135630272
edi            0x5      5
eip            0xf7dd7086       0xf7dd7086
<_bfd_elf_compute_section_file_positions+11174>
eflags         0x10202  [ IF RF ]
cs             0x23     35
ss             0x2b     43
ds             0x2b     43
es             0x2b     43
fs             0x0      0
gs             0x63     99


I'll keep the core file here if there is anything else that needs to be done
with it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]