Subject: Re: bug#30243: 26.0.91; Infinite recursion in `make-auto-save-file-name' for quoted filenames

From: Noam Postavsky <[email-masked]>
Date: Thu, 25 Jan 2018 20:46:18 -0500

Noam Postavsky <[email-masked]> writes:

> On Thu, Jan 25, 2018 at 11:36 AM, Michael Albinus
> <[email-masked]> 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*.