[Bug gold/20942] New: GOLD crashes when running in parallel
https://sourceware.org/bugzilla/show_bug.cgi?id=20942 Bug ID: 20942 Summary: GOLD crashes when running in parallel Product: binutils Version: 2.28 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: boehme.marcel at gmail dot com CC: ian at airs dot com Target Milestone: --- Dear all, The following bug was found with AFLFast, a fork of AFL, in a 24 hour fuzzing session on Binutils. Thanks also to Van-Thuan Pham. The gold linker crashes with a Bus error for the following execution on Ubuntu 16.04 x86_64 in Binutils trunk and for preinstalled version v2.26.1 and on Ubuntu 14.04 x86_64 for Binutils in trunk and preinstalled version v2.24. $ touch a $ for j in $(seq 1 4); do for i in $(seq 1 50); do gold a; done & done 2> error.log $ grep "Bus" error.log Very interesting Heisenbug. With a bit of playing around, I got this from ASAN: ==61901==ERROR: AddressSanitizer: SEGV on unknown address 0x7f2b8019a0b0 (pc 0x01112169 bp 0x7ffe92e07e50 sp 0x7ffe92e07e20 T0) ./gold/ld-new: error: cannot open a: No such file or directory #0 0x1112168 in elfcpp::Sym_write<64, false>::put_st_name(unsigned int) ../../gold/../elfcpp/elfcpp.h:1522 #1 0x16f4fef in void gold::Symbol_table::sized_write_symbol<64, false>(gold::Sized_symbol<64>*, elfcpp::Elf_types<64>::Elf_Addr, unsigned int, elfcpp::STB, gold::Stringpool_template const*, unsigned char*) const ../../gold/symtab.cc:3223 #2 0x16e36e6 in void gold::Symbol_table::sized_write_globals<64, false>(gold::Stringpool_template const*, gold::Stringpool_template const*, gold::Output_symtab_xindex*, gold::Output_symtab_xindex*, gold::Output_file*) const ../../gold/symtab.cc:3139 #3 0x16bb915 in gold::Symbol_table::write_globals(gold::Stringpool_template const*, gold::Stringpool_template const*, gold::Output_symtab_xindex*, gold::Output_symtab_xindex*, gold::Output_file*) const ../../gold/symtab.cc:2938 ./gold/ld-new: error: cannot open a: No such file or directory #4 0x11c4ff3 in gold::Write_symbols_task::run(gold::Workqueue*) ../../gold/layout.cc:5642 #5 0x173d4f5 in gold::Workqueue::find_and_run_task(int) ../../gold/workqueue.cc:319 #6 0x173ec3f in gold::Workqueue::process(int) ../../gold/workqueue.cc:495 #7 0x405d95 in main ../../gold/main.cc:252 #8 0x7f2b83a5bf44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44) #9 0x405147 (./gold/ld-new+0x405147) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV ../../gold/../elfcpp/elfcpp.h:1522 in elfcpp::Sym_write<64, false>::put_st_name(unsigned int) ==61901==ABORTING Best regards, - Marcel -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20932] LD: Internal error during record link assignment
https://sourceware.org/bugzilla/show_bug.cgi?id=20932 --- Comment #3 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c2596ca5d7f6ab6d38882bf0f0fc44fe352afcb1 commit c2596ca5d7f6ab6d38882bf0f0fc44fe352afcb1 Author: Nick Clifton Date: Wed Dec 7 10:19:42 2016 + Fix internal error in the linker by replacing a call to abort with an error message. PR ld/20932 * elflink.c (bfd_elf_record_link_assignment): Replace call to abort with an error message and error return value. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20932] LD: Internal error during record link assignment
https://sourceware.org/bugzilla/show_bug.cgi?id=20932 --- Comment #4 from Nick Clifton --- Hi Marcel, Well, I still cannot reproduce the problem. But I can apply a patch which replaces the call to abort() with an error message instead. Please could you try out the latest sources and let me know if this fixes the problem ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20932] LD: Internal error during record link assignment
https://sourceware.org/bugzilla/show_bug.cgi?id=20932 --- Comment #6 from Alan Modra --- Oh, and reproduce on a --target=x86_64-linux binutils. --enable-targets=all give too many possible matches for the aout test object. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20932] LD: Internal error during record link assignment
https://sourceware.org/bugzilla/show_bug.cgi?id=20932 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #5 from Alan Modra --- Created attachment 9692 --> https://sourceware.org/bugzilla/attachment.cgi?id=9692&action=edit alternate fix Nick, we really shouldn't ever get a warning symbol there. The testcase object contains a fuzzed symbol table that has global symbols with an empty string for their name. I reckon such symbols should not be allowed and I think it would make more sense to error closer to the cause of the problem rather than on one of the symptoms. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20932] LD: Internal error during record link assignment
https://sourceware.org/bugzilla/show_bug.cgi?id=20932 --- Comment #7 from Nick Clifton --- Hi Alan, > Nick, we really shouldn't ever get a warning symbol there. The testcase > object contains a fuzzed symbol table that has global symbols with an empty > string for their name. I reckon such symbols should not be allowed and I > think it would make more sense to error closer to the cause of the problem > rather than on one of the symptoms. Fair enough - please go ahead with your fix. I think that my patch should remain however, possibly with a changed error message, as I am not a fan of calls to abort() inside a library. In my opinion a library call should never end up with a seg-fault if it is possible to return to the caller with an error condition set. Even for something that is never expected to happen. Cheers Nick PS. I was finally able to reproduce the problem, but only with a toolchain configured for an i686-pc-inux-gnu target rather than x86_64-pc-linux-gnu. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/20946] New: lookup_mach_via_bfd_name aborts
https://sourceware.org/bugzilla/show_bug.cgi?id=20946
Bug ID: 20946
Summary: lookup_mach_via_bfd_name aborts
Product: binutils
Version: 2.28 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: qiyao at gcc dot gnu.org
Target Milestone: ---
I configured gdb with all targets enabled "--enable-targets=all
--enable-64-bit-bfd --disable-binutils --disable-gprof --disable-gold
--disable-gas --disable-ld".
If I change arch to "fr300", and do disassembly, lookup_mach_via_bfd_name
aborts.
(gdb) set architecture fr300
The target architecture is assumed to be fr300
(gdb) disassemble 0x0,+4
Dump of assembler code from 0x0 to 0x4:
0x:
Program received signal SIGABRT, Aborted.
0x763c3cc9 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt 20
#0 0x763c3cc9 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x763c70d8 in __GI_abort () at abort.c:89
#2 0x0088bbad in lookup_mach_via_bfd_name (table=0x1472ee8
, name=0x17afc51 "fr300")
at /home/yao/SourceCode/gnu/gdb/git/opcodes/frv-desc.c:6176
#3 0x0088c2df in frv_cgen_cpu_open (arg_type=CGEN_CPU_OPEN_BFDMACH) at
/home/yao/SourceCode/gnu/gdb/git/opcodes/frv-desc.c:6387
#4 0x00811c72 in print_insn_frv (pc=0, info=0x7fffd940) at
/home/yao/SourceCode/gnu/gdb/git/opcodes/frv-dis.c:784
#5 0x00679e87 in gdb_pretty_print_insn (gdbarch=0x26cb970,
uiout=0x21a2700, di=0x7fffd940, insn=0x7fffd850, flags=0,
stb=0x26ccef0)
at /home/yao/SourceCode/gnu/gdb/git/gdb/disasm.c:281
#6 0x0067a0ae in dump_insns (gdbarch=0x26cb970, uiout=0x21a2700,
di=0x7fffd940, low=0, high=4, how_many=-1, flags=0, stb=0x26ccef0,
end_pc=0x0)
at /home/yao/SourceCode/gnu/gdb/git/gdb/disasm.c:347
#7 0x0067b3d3 in do_assembly_only (gdbarch=0x26cb970, uiout=0x21a2700,
di=0x7fffd940, low=0, high=4, how_many=-1, flags=0, stb=0x26ccef0)
at /home/yao/SourceCode/gnu/gdb/git/gdb/disasm.c:789
#8 0x0067b67f in gdb_disassembly (gdbarch=0x26cb970, uiout=0x21a2700,
file_string=0x0, flags=0, how_many=-1, low=0, high=4)
at /home/yao/SourceCode/gnu/gdb/git/gdb/disasm.c:855
#9 0x005965bb in print_disassembly (gdbarch=0x26cb970, name=, low=0, high=4, flags=0)
at /home/yao/SourceCode/gnu/gdb/git/gdb/cli/cli-cmds.c:1151
#10 0x00597516 in print_disassembly (flags=0, high=4, low=0, name=0x0,
gdbarch=0x26cb970) at /home/yao/SourceCode/gnu/gdb/git/gdb/cli/cli-cmds.c:1140
#11 disassemble_command (arg=, from_tty=) at
/home/yao/SourceCode/gnu/gdb/git/gdb/cli/cli-cmds.c:1303
#12 0x0059ac33 in cmd_func (cmd=0x20cb600, args=0x26becfc "0x0,+4",
from_tty=1) at /home/yao/SourceCode/gnu/gdb/git/gdb/cli/cli-decode.c:1913
#13 0x0078a3f6 in execute_command (p=, p@entry=0x26becf0
"disassemble 0x0,+4", from_tty=1)
at /home/yao/SourceCode/gnu/gdb/git/gdb/top.c:674
#14 0x006b538c in command_handler (command=0x26becf0 "disassemble
0x0,+4") at /home/yao/SourceCode/gnu/gdb/git/gdb/event-top.c:550
#15 0x006b5688 in command_line_handler (rl=) at
/home/yao/SourceCode/gnu/gdb/git/gdb/event-top.c:740
... because it can't find "fr300" in frv_cgen_mach_table,
(gdb) p frv_cgen_mach_table
$1 = {{name = 0x1471cd5 "frv", bfd_name = 0x1471cd5 "frv", num = 1,
insn_chunk_bitsize = 0}, {name = 0x1471cd9 "fr550", bfd_name = 0x1471cd9
"fr550",
num = 2, insn_chunk_bitsize = 0}, {name = 0x1471cdf "fr500", bfd_name =
0x1471cdf "fr500", num = 3, insn_chunk_bitsize = 0}, {name = 0x1471cf1
"tomcat",
bfd_name = 0x1471cf1 "tomcat", num = 6, insn_chunk_bitsize = 0}, {name =
0x1471ceb "fr400", bfd_name = 0x1471ceb "fr400", num = 5,
insn_chunk_bitsize = 0}, {name = 0x1471ce5 "fr450", bfd_name = 0x1471ce5
"fr450", num = 4, insn_chunk_bitsize = 0}, {name = 0x1471cf8 "simple",
bfd_name = 0x1471cf8 "simple", num = 7, insn_chunk_bitsize = 0}, {name =
0x0, bfd_name = 0x0, num = 0, insn_chunk_bitsize = 0}}
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20932] LD: Internal error during record link assignment
https://sourceware.org/bugzilla/show_bug.cgi?id=20932 --- Comment #8 from Marcel Böhme --- Thanks Nick. Thanks Alan. Works fine now. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/20522] linking powerpc64le Linux kernel with --emit-relocs causes internal error in set_info_section, at output.h:3386
https://sourceware.org/bugzilla/show_bug.cgi?id=20522 --- Comment #4 from npiggin at gmail dot com --- Confirmed again, the internal error only occurs when linking with *(.rela*), and not with *(.rela.dyn). It would be nice to turn this into a useful error message, but importance could be reduced. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/20878] gold powerpc64 le linux fails to link large Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=20878 --- Comment #6 from npiggin at gmail dot com --- This commit fixes the bug for me. Thank you. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
