[Bug ld/31009] regression: assertion fail ../../bfd/merge.c:243

[jonny.weir at clearpool dot io]

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

--- Comment #3 from Jonny Weir <jonny.weir at clearpool dot io> ---
Hi Nick,

(In reply to Nick Clifton from comment #1)
> 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 ?

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:

I attached gdb to the ld process, but I think a few things happen that make it
more difficult to get a stack trace. I believe it forks another process and
that is the process that spits out the assertion messages, so when that
returns, there is no stack to examine. Unless there is a way to do this that I
don't see, I cant see how to get the required stack trace.

> 
>   // 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.
> 

On the plus side, I have been able to checkout this commit and successfully
build it and attempt my builds using the newly built version of ld. As
expected, it spits out the same lines:

/bin/ld: BFD (GNU Binutils) 2.40.50.20230120 assertion fail merge.c:243

> 
> > 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 ?

Yes, this would work, seeing as I can build ld from the specific commit you
mention above.

> 
> Cheers
>   Nick

Many thanks for the prompt response,

Jonny

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