Issue 60972 in oss-fuzz: binutils:fuzz_disas_ext-bfd_arch_arm: Abrt in print_insn_mve
Updates: Labels: -deadline-approaching -restrict-view-commit Deadline-Exceeded Comment #3 on issue 60972 by sheriffbot: binutils:fuzz_disas_ext-bfd_arch_arm: Abrt in print_insn_mve https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=60972#c3 This bug has exceeded our disclosure deadline. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 61258 in oss-fuzz: binutils:fuzz_as: Unexpected-exit in xexit
Updates: Labels: Deadline-Approaching Comment #2 on issue 61258 by sheriffbot: binutils:fuzz_as: Unexpected-exit in xexit https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=61258#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
[Bug ld/31009] regression: assertion fail ../../bfd/merge.c:243
https://sourceware.org/bugzilla/show_bug.cgi?id=31009 --- Comment #2 from Michael Matz --- Another possible way forward: if you add '-save-temps' to the link/compile command then the LTO phase will leave around the $foobar.ltransXXX.ltrans.o files and the *.debug.o files, that are ultimately input to the second linker phase (the one that throws these errors). If you can provide access to these, plus the other linker input files and command line (also see the output when adding '-v', search for "collect2" and COLLECT_GCC_OPTIONS), then we could also analyse the causes. The ltrans and .debug files will also be very large, though. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31009] regression: assertion fail ../../bfd/merge.c:243
https://sourceware.org/bugzilla/show_bug.cgi?id=31009 Michael Matz changed: What|Removed |Added CC||matz at suse dot de -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31009] regression: assertion fail ../../bfd/merge.c:243
https://sourceware.org/bugzilla/show_bug.cgi?id=31009 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi Jonny, (In reply to Jonny Weir from comment #0) > linking stage when -O3 is used (-O2 builds and links correctly). To be > clear, the only difference between success and failure is the optimisation > level that is used. And to be even more clear, you are talking about the compiler's optimization level and not the linker's, correct ? > /bin/ld: BFD (GNU Binutils for Debian) 2.41 assertion fail > ../../bfd/merge.c:243 Are you able to attach a debugger to the linker and discover the values that are triggering this assertion ? The code looks like this: // We must not need resizing, otherwise _index is wrong BFD_ASSERT (bfdtab->count + 1 <= table->nbuckets * 2 / 3); So it would be interesting to know the values of bfdtab->count and table->nbuckets. Given that you are linking a very large project, I do wonder if the problem is that one of these fields is overflowing. Are you able to build a version of the linker with undefined behaviour sanitization enabled and then find out if that catches something ? > I appreciate that this description is quite vague without an example piece > of code to illustrate the problem, but something appears to have been > changed that causes this recursive output of messages upon failure. The change was (almost certainly) commit 1a528d3ef07f, which reworked the string merge code to greatly improve its speed. So far the changes have proved to be very robust, but it may be that this is the first time that they have been asked to handle an extremely large project. > Unfortunately, due to the nature and complexity of the project, I have been > unable > to provide a code example that generates the above output. As an alternative, if we are able to offer you patches (to the linker) to try out, are you able to apply and build your own linker to use for testing ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31009] New: regression: assertion fail ../../bfd/merge.c:243
https://sourceware.org/bugzilla/show_bug.cgi?id=31009 Bug ID: 31009 Summary: regression: assertion fail ../../bfd/merge.c:243 Product: binutils Version: 2.41 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: jonny.weir at clearpool dot io Target Milestone: --- Hi, I am building a complex, large-scale C++23 project using gcc12 in Debian Linux (sid) with kernel 6.5.0-1-amd64. When using binutils 2.39, the linking stage is successful whether the project was built using the -O2 or -O3 flag. However, upon testing binutils 2.41, there appears to be an issue with the linking stage when -O3 is used (-O2 builds and links correctly). To be clear, the only difference between success and failure is the optimisation level that is used. Work flow (with includes and full paths removed): g++-12 -o main.o -c -std=c++2b -fexceptions -fconcepts -fcoroutines -flto=auto -Wall -g -O3 main.cpp g++-12 -o output -flto=auto -rdynamic -Wl,-rpath=. -Xlinker -Bstatic -lpthread -lrt -lcurl -lssl -lcrypto I get the following output: /bin/ld: BFD (GNU Binutils for Debian) 2.41 assertion fail ../../bfd/merge.c:243 /bin/ld: BFD (GNU Binutils for Debian) 2.41 assertion fail ../../bfd/merge.c:243 /bin/ld: BFD (GNU Binutils for Debian) 2.41 assertion fail ../../bfd/merge.c:243 ... /bin/ld: BFD (GNU Binutils for Debian) 2.41 assertion fail ../../bfd/merge.c:243 /bin/ld: BFD (GNU Binutils for Debian) 2.41 assertion fail ../../bfd/merge.c:243 /bin/ld: BFD (GNU Binutils for Debian) 2.41 assertion fail ../../bfd/merge.c:243 /bin/ld: BFD (GNU Binutils for Debian) 2.41 assertion fail ../../bfd/merge.c:243 /bin/ld: BFD (GNU Binutils for Debian) 2.41 assertion fail ../../bfd/merge.c:243 /bin/ld: /tmp/ccmkypk7.ltrans0.ltrans.o: access beyond end of merged section (4) /bin/ld: /tmp/ccmkypk7.ltrans0.ltrans.o: access beyond end of merged section (4) /bin/ld: /tmp/ccmkypk7.ltrans0.ltrans.o: access beyond end of merged section (20) /bin/ld: /tmp/ccmkypk7.ltrans0.ltrans.o: access beyond end of merged section (33) /bin/ld: /tmp/ccmkypk7.ltrans0.ltrans.o: access beyond end of merged section (41) /bin/ld: /tmp/ccmkypk7.ltrans0.ltrans.o: access beyond end of merged section (48) /bin/ld: /tmp/ccmkypk7.ltrans0.ltrans.o: access beyond end of merged section (60) /bin/ld: /tmp/ccmkypk7.ltrans0.ltrans.o: access beyond end of merged section (71) /bin/ld: /tmp/ccmkypk7.ltrans0.ltrans.o: access beyond end of merged section (85) /bin/ld: /tmp/ccmkypk7.ltrans0.ltrans.o: access beyond end of merged section (95) ... /bin/ld: /tmp/ccmkypk7.ltrans0.ltrans.o: access beyond end of merged section (289) /bin/ld: /tmp/ccmkypk7.ltrans0.ltrans.o: access beyond end of merged section (289) /bin/ld: /tmp/ccmkypk7.ltrans0.ltrans.o: access beyond end of merged section (278) /bin/ld: /tmp/ccmkypk7.ltrans0.ltrans.o: access beyond end of merged section (278) collect2: error: ld returned 1 exit status The output has been snipped for brevity. There are a total of 751340 lines of assertion fail output and 193 lines of output that contain the "access beyond end" message. Unfortunately, due to the nature and complexity of the project, I have been unable to provide a code example that generates the above output. I appreciate that this description is quite vague without an example piece of code to illustrate the problem, but something appears to have been changed that causes this recursive output of messages upon failure. -- You are receiving this mail because: You are on the CC list for the bug.
