GNU bug report logs -
#49261
28.0.50; File Locking Breaks Presumptuous Toolchains
Previous Next
Reported by: Mallchad Skeghyeph <ncaprisunfan <at> gmail.com>
Date: Mon, 28 Jun 2021 18:28:02 UTC
Severity: normal
Found in version 28.0.50
Fixed in version 28.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, michael.albinus <at> gmx.de,
> ncaprisunfan <at> gmail.com, 49261 <at> debbugs.gnu.org, Paul Eggert
> <eggert <at> cs.ucla.edu>
> Date: Sat, 10 Jul 2021 19:15:53 +0200
>
> >> 731 return lisp_h_XLP (o);
> >> (gdb) bt
> >> #0 0x00005555556f0549 in AREF (idx=6988131860, array=XIL(0x7ffff1bd901d))
> >> at lisp.h:731
> >> #1 HASH_KEY (idx=3494065930, h=0x7ffff1bd8f98) at lisp.h:2374
> >> #2 hash_lookup
> >> (h=0x7ffff1bd8f98, key=XIL(0x555555c76c64), hash=hash <at> entry=0x0)
> >> at fns.c:4479
>
> Well, the segfault is in this:
>
> for (i = HASH_INDEX (h, start_of_bucket); 0 <= i; i = HASH_NEXT (h, i))
> {
>
> and you can see that idx (i.e., i here) is 3494065930, which is a very
> unusual value for idx -- it's usually below 2K. So it can't really be
> anything other than a memory corruption issue, I think?
Yes, but why? and in which hash-table?
This bug report was last modified 4 years and 39 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.