bug#39962: 27.0.90; Crash in Emacs 27.0.90

[Pieter van Oostrum]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 7 Mar 2020 00:55:39 +0100
>> From: Pieter van Oostrum <pieter@vanoostrum.org>
>> 
>> I got a segmentation fault in Emacs. I read my email with VM
>> (Viewmail), and I had a few fairly large mailboxes open when Emacs
>> crashed. I had a few other cases where it crashed under similar
>> circumstances, but other cases where it ran without problems.
>> 
>> I have the crashed instance under gdb, and I will keep it some time
>> there to be able to extract more info. For the time being it looks
>> like it is in the garbage collector.
>> 
>> The backtrace is very large, so it could be a stack overflow.
>
> Please show the first few backtrace frames (with "bt 10", for
> example), they are important for trying to figure out whether this was
> a stack overflow or something else.

I managed to reproduce another crash, but now it gives an assertion failure 
rather than a segmentation violation, which is much better IMHO.

insdel.c:295: Emacs fatal error: assertion failed: m->bytepos >= m->charpos && 
m->bytepos - m->charpos <= Z_BYTE - Z
--Type <RET> for more, q to quit, c to continue without paging--
insdel.c:295: Emacs fatal error: assertion failed: m->bytepos >= m->charpos && 
m->bytepos - m->charpos <= Z_BYTE - Z
--Type <RET> for more, q to quit, c to continue without paging--

Thread 3 hit Breakpoint 1, terminate_due_to_signal (sig=6, 
    backtrace_limit=2147483647) at emacs.c:371
371       signal (sig, SIG_DFL);
(gdb) bt 10
#0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:371
#1  0x00000001002a4abb in die (
    msg=0x10050ff57 "m->bytepos >= m->charpos && m->bytepos - m->charpos <= 
Z_BYTE - Z", file=0x10050fdda "insdel.c", line=295) at alloc.c:7246
#2  0x0000000100233af4 in adjust_markers_for_insert (from=36399, 
    from_byte=36399, to=36401, to_byte=36401, before_markers=false)
    at insdel.c:294
#3  0x00000001002344d0 in insert_from_string_1 (string=XIL(0x15b29a904), 
    pos=0, pos_byte=0, nchars=2, nbytes=2, inherit=false, before_markers=false)
    at insdel.c:1060
#4  0x0000000100233e18 in insert_from_string (string=XIL(0x15b29a904), pos=0, 
    pos_byte=0, length=2, length_byte=2, inherit=false) at insdel.c:967
#5  0x00000001002ec4c2 in general_insert_function (
    insert_func=0x1002320b0 <insert>, 
    insert_from_string_func=0x100233d80 <insert_from_string>, inherit=false, 
    nargs=1, args=0x7ffeefbf5ce8) at editfns.c:1334
#6  0x00000001002ec1db in Finsert (nargs=1, args=0x7ffeefbf5ce8)
    at editfns.c:1370
#7  0x00000001003a7d53 in exec_byte_code (bytestr=XIL(0x10d25eb84), 
    vector=XIL(0x10e0fc055), maxdepth=make_fixnum(6), args_template=XIL(0), 
    nargs=0, args=0x0) at bytecode.c:1075
#8  0x0000000100317436 in funcall_lambda (fun=XIL(0x10e0fde35), nargs=1, 
    arg_vector=0x7ffeefbf6e80) at eval.c:3067
#9  0x0000000100314bfe in Ffuncall (nargs=2, args=0x7ffeefbf6e78)
    at eval.c:2796
(More stack frames follow...)
[New Thread 0x1c8f of process 52920]
[New Thread 0x521b of process 52920]

Lisp Backtrace:
Cannot access memory at address 0xcfeb5c0
(gdb) 

-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]