[Bug ld/31009] regression: assertion fail ../../bfd/merge.c:243
https://sourceware.org/bugzilla/show_bug.cgi?id=31009 Sam James changed: What|Removed |Added CC||sam at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
Issue 61258 in oss-fuzz: binutils:fuzz_as: Unexpected-exit in xexit
Updates: Labels: -deadline-approaching -restrict-view-commit Deadline-Exceeded Comment #3 on issue 61258 by sheriffbot: binutils:fuzz_as: Unexpected-exit in xexit https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=61258#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.
[Bug ld/31009] regression: assertion fail ../../bfd/merge.c:243
https://sourceware.org/bugzilla/show_bug.cgi?id=31009
--- Comment #11 from Jonny Weir ---
Hi Michael,
(In reply to Michael Matz from comment #10)
> (In reply to Jonny Weir from comment #7)
> > I made the following change:
>
> Thanks!
>
> > XXX resize 1: count=1598 added=1086327410 newnb=1048576
>
> ...
>
> The error is in another overflow in the check:
>
> if (bfdtab->count + added > table->nbuckets * 2 / 3)
> {
> unsigned i;
> unsigned long newnb = table->nbuckets * 2;
> ... rest of resize code ...
>
> as table->nbuckets is 2G at entry to this, the expression table->nbuckets * 2
> is going to be zero, so once nbuckets goes to 2G (the max supported size)
> the above expression will always be true, we always go into the resize case,
> and we always will fail it (with the followup errors then occurring).
>
> Let's rewrite it into "/ 3 * 2" to avoid overflow in the check. Can you test
> this, please? (patch still contains the printf debugs):
I have just tested this and I now have the following output along with a fully
built binary:
XXX resize 1: count=566 added=6620 newnb=16384
XXX resize 2: newnb=16384
XXX resize 1: count=1136 added=28767 newnb=32768
XXX resize 2: newnb=65536
XXX resize 1: count=113 added=7711 newnb=16384
XXX resize 2: newnb=16384
XXX resize 1: count=264 added=10768 newnb=32768
XXX resize 2: newnb=32768
XXX resize 1: count=441 added=40265 newnb=65536
XXX resize 2: newnb=65536
XXX resize 1: count=677 added=120326 newnb=131072
XXX resize 2: newnb=262144
XXX resize 1: count=1047 added=212455 newnb=524288
XXX resize 2: newnb=524288
XXX resize 1: count=1594 added=1124529454 newnb=1048576
XXX resize 2: newnb=2147483648
This fix appears to do the job! Many thanks for the fast resolution of this
issue.
> ...
--
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
--- Comment #10 from Michael Matz ---
(In reply to Jonny Weir from comment #7)
> I made the following change:
Thanks!
> XXX resize 1: count=1598 added=1086327410 newnb=1048576
Gah, yeah. So, one of the input string sections (most likely one of the
.debug_str sections) is about 2GB in size. We overestimate this (quite much)
to add 1G strings, which ...
> XXX resize 2: newnb=2147483648
... seems to work fine, still ...
> XXX resize 1: count=755248 added=68141 newnb=0
> false1: newnb=0
... but then, when we've already allocated 2G buckets (and used 755248 of
those),
we fail to add space for another (estimated) 68141 ones. (We fail to do so,
because we can't double the number of buckets again, as it's only a unsigned
int). Why that leads to errors down the pipe I can't quite see yet, these
input sections which can't be added to the hash table for $reason are supposed
to be ignored and just added as is into the output. But whatever the reason
for _that_ is doesn't matter at first. The first thing that goes wrong
is already that we go into the resize-me case at all with these numbers.
When we have 2 billion buckets, of which 755k are used, and want to add
(potentially) another 68k, then obviously we don't need to resize anything.
The existing 2G buckets should be enough :-)
The error is in another overflow in the check:
if (bfdtab->count + added > table->nbuckets * 2 / 3)
{
unsigned i;
unsigned long newnb = table->nbuckets * 2;
... rest of resize code ...
as table->nbuckets is 2G at entry to this, the expression table->nbuckets * 2
is going to be zero, so once nbuckets goes to 2G (the max supported size)
the above expression will always be true, we always go into the resize case,
and we always will fail it (with the followup errors then occurring).
Let's rewrite it into "/ 3 * 2" to avoid overflow in the check. Can you test
this, please? (patch still contains the printf debugs):
diff --git a/bfd/merge.c b/bfd/merge.c
index 722e6659486..f81cd30197f 100644
--- a/bfd/merge.c
+++ b/bfd/merge.c
@@ -167,7 +167,7 @@ static bool
sec_merge_maybe_resize (struct sec_merge_hash *table, unsigned added)
{
struct bfd_hash_table *bfdtab = &table->table;
- if (bfdtab->count + added > table->nbuckets * 2 / 3)
+ if (bfdtab->count + added > table->nbuckets / 3 * 2)
{
unsigned i;
unsigned long newnb = table->nbuckets * 2;
@@ -175,12 +175,14 @@ sec_merge_maybe_resize (struct sec_merge_hash *table,
unsigned added)
uint64_t *newl;
unsigned long alloc;
- while (bfdtab->count + added > newnb * 2 / 3)
+ printf ("XXX resize 1: count=%u added=%u newnb=%lu\n", bfdtab->count,
added, newnb);
+ while (bfdtab->count + added > newnb / 3 * 2)
{
newnb *= 2;
if (!newnb)
return false;
}
+ printf ("XXX resize 2: newnb=%lu\n", newnb);
alloc = newnb * sizeof (newl[0]);
if (alloc / sizeof (newl[0]) != newnb)
@@ -240,7 +242,7 @@ sec_merge_hash_insert (struct sec_merge_hash *table,
hashp->u.suffix = NULL;
hashp->next = NULL;
// We must not need resizing, otherwise _index is wrong
- BFD_ASSERT (bfdtab->count + 1 <= table->nbuckets * 2 / 3);
+ BFD_ASSERT (bfdtab->count + 1 <= table->nbuckets / 3 * 2);
bfdtab->count++;
table->key_lens[_index] = (hash << 32) | (uint32_t)len;
table->values[_index] = hashp;
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/30865] ld: =fillexp different behaviors for hexidecimal literal
https://sourceware.org/bugzilla/show_bug.cgi?id=30865 Nick Clifton changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Nick Clifton --- Thanks for the typo correction. I have updated the comments in the test script to make them more uniform, and then checked in the patch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30865] ld: =fillexp different behaviors for hexidecimal literal
https://sourceware.org/bugzilla/show_bug.cgi?id=30865 --- Comment #6 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=f1837d9c3f2dc2a5c232f4eae4c4bd5a7f77baf8 commit f1837d9c3f2dc2a5c232f4eae4c4bd5a7f77baf8 Author: Nick Clifton Date: Mon Nov 6 13:59:53 2023 + ld: =fillexp different behaviors for hexidecimal literal PR 30865 * ld.texi: Update description of the FILL command. * testsuite/ld-scripts/fill2.d: New test. * testsuite/ld-scripts/fill2.t: New test source. * testsuite/ld-scripts/data.exp: Run the new test. -- You are receiving this mail because: You are on the CC list for the bug.
