Description of problem: This coredump happens for the following situation. I have a C++ file generic.cpp with this content: int hello() { return 42; } Then I execute the following two commands: g++ -c generic.cpp -o generic.x86_32.o -m32 -flto -pipe gcc-ar cDrs libgeneric.x86_32.a generic.x86_32.o Expected behavior is for gcc-ar not to crash. Version-Release number of selected component: binutils-2.25-15.fc23 Additional info: reporter: libreport-2.6.4 backtrace_rating: 4 cmdline: /usr/bin/ar --plugin /usr/libexec/gcc/x86_64-redhat-linux/5.3.1/liblto_plugin.so -cDrs libgeneric.x86_32.a generic.x86_32.o crash_function: _IO_new_file_seekoff executable: /usr/bin/ar global_pid: 23105 kernel: 4.3.5-300.fc23.x86_64 runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #0 _IO_new_file_seekoff at fileops.c:1134 #1 fseeko at fseeko.c:39 #2 bfd_seek at bfdio.c:325 #3 pe_bfd_object_p at peicode.h:1275 #4 bfd_check_format_matches at format.c:335 #5 bfd_plugin_get_symbols_in_object_only at plugin.c:156 #6 add_symbols at plugin.c:278 #7 claim_file_handler at ../../lto-plugin/lto-plugin.c:978 #8 try_claim at plugin.c:331 #9 try_load_plugin at plugin.c:384
Created attachment 1129960 [details] File: backtrace
Created attachment 1129961 [details] File: cgroup
Created attachment 1129962 [details] File: core_backtrace
Created attachment 1129963 [details] File: dso_list
Created attachment 1129964 [details] File: environ
Created attachment 1129965 [details] File: exploitable
Created attachment 1129966 [details] File: limits
Created attachment 1129967 [details] File: maps
Created attachment 1129968 [details] File: mountinfo
Created attachment 1129969 [details] File: namespaces
Created attachment 1129970 [details] File: open_fds
Created attachment 1129971 [details] File: proc_pid_status
Created attachment 1129972 [details] File: var_log_messages
Hi Julian, Please could you upload copies of libgeneric.x86_32.a and generic.x86_32.o so that I can reproduce the problem locally ? Cheers Nick
For me it trivially reproduces even with an "empty" object file: % rm -f foo.o lib.a % touch foo.cpp % g++ -c foo.cpp -m32 -flto % gcc-ar cDrs lib.a foo.o I am attaching the object file for convencience. With that the bug reproduces with the last gcc-ar call.
Created attachment 1130903 [details] Object file that triggers the gcc-ar crash
Thanks Julian - that crash.o file was exactly what I needed. Please try: binutils-2.25-17.fc23 which should fix the bug.
With binutils-2.25-17.fc23 I cannot reproduce the bug anymore. Thanks!
Is there a rough timeline when the updated binutils will be pushed to fedora-updates?
binutils-2.25-17.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-3ee715a535
binutils-2.25-17.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-3ee715a535
binutils-2.25-17.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.