GNU bug report logs - #30243
26.0.91; Infinite recursion in `make-auto-save-file-name' for quoted filenames

Previous Next

Package: emacs;

Reported by: phst <at> a.muc.corp.google.com

Date: Wed, 24 Jan 2018 22:23:01 UTC

Severity: normal

Tags: fixed

Found in version 26.0.91

Fixed in version 26.1

Done: Noam Postavsky <npostavs <at> users.sourceforge.net>

Bug is archived. No further changes may be made.

Full log


Message #32 received at 30243 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 30243 <at> debbugs.gnu.org, Philipp Stephani <p.stephani2 <at> gmail.com>
Subject: Re: bug#30243: 26.0.91;
 Infinite recursion in `make-auto-save-file-name' for quoted filenames
Date: Thu, 25 Jan 2018 20:46:18 -0500
Noam Postavsky <npostavs <at> users.sourceforge.net> writes:

> On Thu, Jan 25, 2018 at 11:36 AM, Michael Albinus
> <michael.albinus <at> gmx.de> wrote:
>
>> Emacs is frozen, and there is the error message in the shell Emacs is
>> started from:
>>
>> emacs: malloc.c:2427: sysmalloc: Assertion `(old_top == initial_top
>> (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE &&
>> prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1))
>> == 0)' failed.
>> Fatal error 6: Aborted
>
> Oh, that's what I got from `file-name-all-completions' before fixing
> it. My guess is that it's due to stack overflow. Although it is a bit
> strange to get heap corruption from stack usage, maybe a bad
> interaction with the stack overflow recovery mechanism?

It's not related to stack overflow recovery, it still happens with
attempt-stack-overflow-recovery set to nil.  The problem appears to be
that we hit the limit in grow_specpdl(), and then call signal_error
which does Ffuncall and then record_in_backtrace writes to specdl, this
latter write is invalid since we failed to grow specdl before.  Thus
memory corruption, undefined behaviour, etc.

#0  0x000000000063999d in record_in_backtrace (function=XIL(0xd9ea380), args=0xffef5b188, nargs=2)
    at ../../src/eval.c:2096
#1  0x000000000063b8c9 in Ffuncall (nargs=3, args=0xffef5b180) at ../../src/eval.c:2746
#2  0x000000000063b320 in call2 (fn=XIL(0xd9ea380), arg1=XIL(0x5250), arg2=XIL(0x1161fc03))
    at ../../src/eval.c:2625
#3  0x00000000006381db in signal_or_quit (error_symbol=XIL(0x5250), data=XIL(0x1161fc03), 
    keyboard_quit=false) at ../../src/eval.c:1565
#4  0x000000000063806d in Fsignal (error_symbol=XIL(0x5250), data=XIL(0x1161fc03))
    at ../../src/eval.c:1514
#5  0x000000000057939a in xsignal (error_symbol=XIL(0x5250), data=XIL(0x1161fc03))
    at ../../src/lisp.h:3861
#6  0x0000000000638704 in signal_error (s=0x75e388 "Variable binding depth exceeds max-specpdl-size", 
    arg=XIL(0)) at ../../src/eval.c:1688
#7  0x00000000006398cd in grow_specpdl () at ../../src/eval.c:2080
(More stack frames follow...)

Lisp Backtrace:
"stringp" (0xfef5b398)
"file-name-non-special" (0xfef5bb58)
"file-newer-than-file-p" (0xfef5bf38)
"apply" (0xfef5c130)
"file-name-non-special" (0xfef5c6f8)
"file-newer-than-file-p" (0xfef5c998)
"apply" (0xfef5cb90)
"file-name-non-special" (0xfef5d158)
"file-newer-than-file-p" (0xfef5d3f8)
"apply" (0xfef5d5f0)
"file-name-non-special" (0xfef5dbb8)
"file-newer-than-file-p" (0xfef5de58)
"apply" (0xfef5e050)
[...]

> I'll take a look at the edebug problems later today.

Turns out this is just Bug#10577.  You can work around it by loading
subr-x before instrumenting forms which use when-let*.




This bug report was last modified 7 years and 192 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.