Subject: bug#68244: hash-table improvements

From: Eli Zaretskii <[email-masked]>
Date: Wed, 17 Jan 2024 05:31:24 +0200

> From: Andy Moreton <[email-masked]>
> Date: Tue, 16 Jan 2024 21:57:04 +0000
> 
> On Mon 15 Jan 2024, Mattias Engdegård wrote:
> 
> > 15 jan. 2024 kl. 13.31 skrev Eli Zaretskii <[email-masked]>:
> >
> >>> Bisect identifies this as the bad commit:
> >>>  d3cefd3e9835 ("Leaner hash table dumping and thawing")
> >
> > Thank you, I can reproduce the (or at least an) assertion failure in this
> > commit. However it's probably a ghost error: although I've tried to make sure
> > that there is a correct build at each point, there have been a lot of work
> > going on rearranging things for correctness and clarity, and apparently I
> > never built this particular one with checking enabled the last time.
> >
> > However this assertion should be removed by the next commit so the error is
> > very short-lived (and it's just an over-zealous assertion, not an actual
> > flaw). What problems do you observe when building master?
> >
> > (And yes, I should update some hashes in pdumper.c; it's been a while.)
> 
> I bisected from newer master to get to that point. Bootstrapping master
> commit f19f5604deb7 ("Update pdumper hashes for buffer and Lisp_Hash_Table")
> is still failing, and trying to continue the buid by retrying after that
> is glacially slow, so something is badly broken at that point.
> 
> Note that the same commit bootstrapped after "git clean -xdf" still has
> multiple backtraces when building without ENABLE_CHECKING.

Can you show the first crash/assertion violation when building with
ENABLE_CHECKING?  It is important to see the error message, and if you
can run the failing command under GDB and show a backtrace, it will be
even more useful.

Thanks.