bug#37575: 27.0.50; Segfault on redisplay

bug#37575: 27.0.50; Segfault on redisplay

[Richard Copley]

[-- Attachment #1: Type: text/plain, Size: 11715 bytes --]

I typed C-w. Emacs crashed.
This was in "emacs -Q" (master), in a message-mode buffer.

Backtraces:

(gdb) bt
#0  0x00007ff9ab4cc803 in KERNELBASE!DebugBreak () from
C:\WINDOWS\System32\KernelBase.dll
#1  0x00000004003862d9 in emacs_abort () at w32fns.c:10802
#2  0x000000040014afee in terminate_due_to_signal (sig=11,
backtrace_limit=40) at emacs.c:401
#3  0x0000000400182aed in handle_fatal_signal (sig=11) at sysdep.c:1790
#4  0x0000000400182ac0 in deliver_thread_signal (sig=11,
handler=0x400182ad5 <handle_fatal_signal>) at sysdep.c:1764
#5  0x0000000400182b29 in deliver_fatal_thread_signal (sig=11) at
sysdep.c:1802
#6  0x000000040043e766 in _gnu_exception_handler (exception_data=0xbf2d40)
    at
E:/mingwbuild/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crt_handler.c:223
#7  0x00007ff9abb58048 in msvcrt!__C_specific_handler () from
C:\WINDOWS\System32\msvcrt.dll
#8  0x00007ff9adb735df in ntdll!.chkstk () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#9  0x00007ff9adb220a9 in ntdll!RtlRaiseException () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#10 0x00007ff9adb7224e in ntdll!KiUserExceptionDispatcher () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#11 0x0000000400217205 in re_match_2_internal (bufp=0x4008fdef0
<searchbufs+752>, string1=0x1600000 "MZ\220",
    size1=179, string2=0x1601569 "", size2=3470, pos=1589, regs=0x400790778
<main_thread+152>, stop=1931)
    at regex-emacs.c:4940
#12 0x000000040021108a in rpl_re_search_2 (bufp=0x4008fdef0
<searchbufs+752>, str1=0x1600000 "MZ\220", size1=179,
    str2=0x1601569 "", size2=3470, startpos=1589, range=342,
regs=0x400790778 <main_thread+152>, stop=1931)
    at regex-emacs.c:3373
#13 0x00000004001fb4b4 in search_buffer_re (string=XIL(0xe420e4), pos=1426,
pos_byte=1426, lim=1932, lim_byte=1932,
    n=1, trt=XIL(0), inverse_trt=XIL(0), posix=false) at search.c:1244
#14 0x00000004001fc373 in search_buffer (string=XIL(0xe420e4), pos=1426,
pos_byte=1426, lim=1932, lim_byte=1932, n=1,
    RE=1, trt=XIL(0), inverse_trt=XIL(0), posix=false) at search.c:1506
#15 0x00000004001facb7 in search_command (string=XIL(0xe420e4),
bound=make_fixnum(1932), noerror=XIL(0x30),
    count=XIL(0), direction=1, RE=1, posix=false) at search.c:1048
#16 0x00000004001fe4ac in Fre_search_forward (regexp=XIL(0xe420e4),
bound=make_fixnum(1932), noerror=XIL(0x30),
    count=XIL(0)) at search.c:2277
#17 0x0000000400275106 in funcall_subr (subr=0x40079c480
<Sre_search_forward>, numargs=3, args=0xbf5500)
    at eval.c:2875
#18 0x0000000400274ca2 in Ffuncall (nargs=4, args=0xbf54f8) at eval.c:2794
#19 0x00000004002e2faa in exec_byte_code (bytestr=XIL(0x8f35554),
vector=XIL(0x8ec9335), maxdepth=make_fixnum(9),
args_template=make_fixnum(257), nargs=1, args=0xbf5a70) at bytecode.c:633
#20 0x00000004002756b5 in funcall_lambda (fun=XIL(0x8ec7fc5), nargs=1,
arg_vector=0xbf5a68) at eval.c:2989
#21 0x0000000400274ce6 in Ffuncall (nargs=2, args=0xbf5a60) at eval.c:2796
#22 0x00000004002e2faa in exec_byte_code (bytestr=XIL(0x4164334),
vector=XIL(0x415dc25), maxdepth=make_fixnum(25),
args_template=make_fixnum(770), nargs=3, args=0xbf6118) at bytecode.c:633
#23 0x00000004002756b5 in funcall_lambda (fun=XIL(0x415dbf5), nargs=3,
arg_vector=0xbf6100) at eval.c:2989
#24 0x0000000400274ce6 in Ffuncall (nargs=4, args=0xbf60f8) at eval.c:2796
#25 0x00000004002e2faa in exec_byte_code (bytestr=XIL(0x428e534),
vector=XIL(0x415d1d5), maxdepth=make_fixnum(14),
args_template=make_fixnum(771), nargs=3, args=0xbf66a0) at bytecode.c:633
#26 0x00000004002756b5 in funcall_lambda (fun=XIL(0x415d1a5), nargs=3,
arg_vector=0xbf6688) at eval.c:2989
#27 0x0000000400274ce6 in Ffuncall (nargs=4, args=0xbf6680) at eval.c:2796
#28 0x00000004002e2faa in exec_byte_code (bytestr=XIL(0x428e734),
vector=XIL(0x415d10d), maxdepth=make_fixnum(7),
args_template=make_fixnum(770), nargs=2, args=0xbf6b68) at bytecode.c:633
#29 0x00000004002756b5 in funcall_lambda (fun=XIL(0x415d0dd), nargs=2,
arg_vector=0xbf6b58) at eval.c:2989
#30 0x0000000400274ce6 in Ffuncall (nargs=3, args=0xbf6b50) at eval.c:2796
#31 0x00000004002e2faa in exec_byte_code (bytestr=XIL(0x42891b4),
vector=XIL(0x902b8d5), maxdepth=make_fixnum(10),
args_template=make_fixnum(257), nargs=1, args=0xbf72b0) at bytecode.c:633
#32 0x00000004002756b5 in funcall_lambda (fun=XIL(0x902b925), nargs=1,
arg_vector=0xbf72a8) at eval.c:2989
#33 0x0000000400274ce6 in Ffuncall (nargs=2, args=0xbf72a0) at eval.c:2796
#34 0x000000040027421f in run_hook_wrapped_funcall (nargs=2, args=0xbf72a0)
at eval.c:2531
#35 0x00000004002744a1 in run_hook_with_args (nargs=2, args=0xbf72a0,
funcall=0x4002741d6 <run_hook_wrapped_funcall>) at eval.c:2612
#36 0x0000000400274271 in Frun_hook_wrapped (nargs=2, args=0xbf72a0) at
eval.c:2546
#37 0x0000000400274f9b in funcall_subr (subr=0x4007a0480
<Srun_hook_wrapped>, numargs=2, args=0xbf72a0) at eval.c:2847
#38 0x0000000400274ca2 in Ffuncall (nargs=3, args=0xbf7298) at eval.c:2794
#39 0x00000004002e2faa in exec_byte_code (bytestr=XIL(0x428929c),
vector=XIL(0x428913d), maxdepth=make_fixnum(19),
args_template=make_fixnum(514), nargs=2, args=0xbf7810) at bytecode.c:633
#40 0x00000004002756b5 in funcall_lambda (fun=XIL(0x428910d), nargs=2,
arg_vector=0xbf7800) at eval.c:2989
#41 0x0000000400274ce6 in Ffuncall (nargs=3, args=0xbf77f8) at eval.c:2796
#42 0x00000004002e2faa in exec_byte_code (bytestr=XIL(0x4289384),
vector=XIL(0x4288e4d), maxdepth=make_fixnum(27),
args_template=make_fixnum(512), nargs=2, args=0xbf7e48) at bytecode.c:633
#43 0x00000004002756b5 in funcall_lambda (fun=XIL(0x4288e1d), nargs=2,
arg_vector=0xbf7e38) at eval.c:2989
#44 0x0000000400274ce6 in Ffuncall (nargs=3, args=0xbf7e30) at eval.c:2796
#45 0x00000004002e2faa in exec_byte_code (bytestr=XIL(0x429230c),
vector=XIL(0x4291f25), maxdepth=make_fixnum(12),
args_template=make_fixnum(257), nargs=1, args=0xbf83d0) at bytecode.c:633
#46 0x00000004002756b5 in funcall_lambda (fun=XIL(0x4291ef5), nargs=1,
arg_vector=0xbf83c8) at eval.c:2989
#47 0x0000000400274ce6 in Ffuncall (nargs=2, args=0xbf83c0) at eval.c:2796
#48 0x00000004002716e7 in internal_condition_case_n (bfun=0x400274b02
<Ffuncall>, nargs=2, args=0xbf83c0, handlers=XIL(0x30), hfun=0x40003ae7e
<safe_eval_handler>) at eval.c:1435
#49 0x000000040003b093 in safe__call (inhibit_quit=false, nargs=2,
func=XIL(0xfffffffc0398b140), ap=0xbf8488 "\001") at xdisp.c:2740
#50 0x000000040003b0f9 in safe_call (nargs=2, func=XIL(0xfffffffc0398b140))
at xdisp.c:2755
#51 0x000000040003b12c in safe_call1 (fn=XIL(0xfffffffc0398b140),
arg=make_fixnum(1426)) at xdisp.c:2766
#52 0x000000040003e0a7 in handle_fontified_prop (it=0xbf9cc0) at
xdisp.c:4062
#53 0x000000040003ce05 in handle_stop (it=0xbf9cc0) at xdisp.c:3590
#54 0x000000040004a47c in next_element_from_buffer (it=0xbf9cc0) at
xdisp.c:8635
#55 0x0000000400046af0 in get_next_display_element (it=0xbf9cc0) at
xdisp.c:7229
#56 0x0000000400072313 in display_line (it=0xbf9cc0, cursor_vpos=40) at
xdisp.c:21903
#57 0x0000000400066a2c in try_window (window=XIL(0x4a32ba5), pos=...,
flags=1) at xdisp.c:17953
#58 0x00000004000643ee in redisplay_window (window=XIL(0x4a32ba5),
just_this_one_p=true) at xdisp.c:17401
#59 0x000000040005d189 in redisplay_window_1 (window=XIL(0x4a32ba5)) at
xdisp.c:15136
#60 0x000000040027155d in internal_condition_case_1 (bfun=0x40005d14a
<redisplay_window_1>, arg=XIL(0x4a32ba5), handlers=XIL(0x4365af3),
hfun=0x40005d0bf <redisplay_window_error>) at eval.c:1379
#61 0x000000040005c43b in redisplay_internal () at xdisp.c:14706
#62 0x000000040005a0fb in redisplay () at xdisp.c:13818
#63 0x00000004001590c8 in read_char (commandflag=1, map=XIL(0xe27813),
prev_event=XIL(0), used_mouse_menu=0xbff22f, end_time=0x0) at
keyboard.c:2472
#64 0x0000000400166a9c in read_key_sequence (keybuf=0xbff460,
prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true,
fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9125
#65 0x00000004001565fb in command_loop_1 () at keyboard.c:1345
#66 0x00000004002714a3 in internal_condition_case (bfun=0x400156121
<command_loop_1>, handlers=XIL(0x90), hfun=0x4001556f9 <cmd_error>) at
eval.c:1355
#67 0x0000000400155d7f in command_loop_2 (ignore=XIL(0)) at keyboard.c:1091
#68 0x0000000400270d47 in internal_catch (tag=XIL(0xdda0), func=0x400155d4d
<command_loop_2>, arg=XIL(0)) at eval.c:1116
#69 0x0000000400155cd3 in command_loop () at keyboard.c:1070
#70 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Lisp Backtrace:
"re-search-forward" (0xbf5500)
0x8ec7fc0 PVEC_COMPILED
"font-lock-fontify-keywords-region" (0xbf6100)
"font-lock-default-fontify-region" (0xbf6688)
"font-lock-fontify-region" (0xbf6b58)
0x902b920 PVEC_COMPILED
"run-hook-wrapped" (0xbf72a0)
"jit-lock--run-functions" (0xbf7800)
"jit-lock-fontify-now" (0xbf7e38)
"jit-lock-function" (0xbf83c8)
"redisplay_internal (C function)" (0x0)



In GNU Emacs 27.0.50 (build 12, x86_64-w64-mingw32)
 of 2019-10-01 built on MACHINE
Repository revision: 72dec8539ea7a0d2fd28bf02abb2d55b329b813f
Repository branch: buster
Windowing system distributor 'Microsoft Corp.', version 10.0.18890
System Description: Microsoft Windows 10 Pro (v10.0.1903.18890.1000)

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --config-cache --with-modules --without-pop --without-dbus
 --without-gconf --without-gsettings 'CFLAGS=-O0 -ggdb3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2
HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS MODULES THREADS JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: ENG
  locale-coding-system: cp1252

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile compile comint ansi-color
ring cconv mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table
term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads w32notify w32 lcms2 multi-tty make-network-process
emacs)

Memory information:
((conses 16 51879 6844)
 (symbols 48 6571 1)
 (strings 32 18260 1549)
 (string-bytes 1 571256)
 (vectors 16 10618)
 (vector-slots 8 133305 9570)
 (floats 8 23 199)
 (intervals 56 220 7)
 (buffers 992 11))

[-- Attachment #2: Type: text/html, Size: 12631 bytes --]

bug#37575: 27.0.50; Segfault on redisplay

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Tue, 1 Oct 2019 20:17:16 +0100
> 
> I typed C-w. Emacs crashed.
> This was in "emacs -Q" (master), in a message-mode buffer.
> 
> Backtraces:
> 
> (gdb) bt
> #0  0x00007ff9ab4cc803 in KERNELBASE!DebugBreak () from C:\WINDOWS\System32\KernelBase.dll
> #1  0x00000004003862d9 in emacs_abort () at w32fns.c:10802
> #2  0x000000040014afee in terminate_due_to_signal (sig=11, backtrace_limit=40) at emacs.c:401
> #3  0x0000000400182aed in handle_fatal_signal (sig=11) at sysdep.c:1790
> #4  0x0000000400182ac0 in deliver_thread_signal (sig=11, handler=0x400182ad5 <handle_fatal_signal>) at
> sysdep.c:1764
> #5  0x0000000400182b29 in deliver_fatal_thread_signal (sig=11) at sysdep.c:1802
> #6  0x000000040043e766 in _gnu_exception_handler (exception_data=0xbf2d40)
>     at E:/mingwbuild/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crt_handler.c:223
> #7  0x00007ff9abb58048 in msvcrt!__C_specific_handler () from C:\WINDOWS\System32\msvcrt.dll
> #8  0x00007ff9adb735df in ntdll!.chkstk () from C:\WINDOWS\SYSTEM32\ntdll.dll
> #9  0x00007ff9adb220a9 in ntdll!RtlRaiseException () from C:\WINDOWS\SYSTEM32\ntdll.dll
> #10 0x00007ff9adb7224e in ntdll!KiUserExceptionDispatcher () from C:\WINDOWS\SYSTEM32\ntdll.dll
> #11 0x0000000400217205 in re_match_2_internal (bufp=0x4008fdef0 <searchbufs+752>, string1=0x1600000
> "MZ\220",
>     size1=179, string2=0x1601569 "", size2=3470, pos=1589, regs=0x400790778 <main_thread+152>,
> stop=1931)
>     at regex-emacs.c:4940

Hmm... I don't see how re_match_2_internal on line 4940 could possibly
cause a fatal signal, and that .chkstk in the backtrace is a hint of
some stack-related problem.  Could it be that the thread that actually
crashed was not the Lisp thread?  If you still have this crashed
sesion inside GDB, please show the result of

  (gdb) thread apply all bt

> #12 0x000000040021108a in rpl_re_search_2 (bufp=0x4008fdef0 <searchbufs+752>, str1=0x1600000
> "MZ\220", size1=179,
>     str2=0x1601569 "", size2=3470, startpos=1589, range=342, regs=0x400790778 <main_thread+152>,
> stop=1931)
>     at regex-emacs.c:3373
> #13 0x00000004001fb4b4 in search_buffer_re (string=XIL(0xe420e4), pos=1426, pos_byte=1426, lim=1932,
> lim_byte=1932,
>     n=1, trt=XIL(0), inverse_trt=XIL(0), posix=false) at search.c:1244
> #14 0x00000004001fc373 in search_buffer (string=XIL(0xe420e4), pos=1426, pos_byte=1426, lim=1932,
> lim_byte=1932, n=1,
>     RE=1, trt=XIL(0), inverse_trt=XIL(0), posix=false) at search.c:1506
> #15 0x00000004001facb7 in search_command (string=XIL(0xe420e4), bound=make_fixnum(1932),
> noerror=XIL(0x30),
>     count=XIL(0), direction=1, RE=1, posix=false) at search.c:1048

It would be also good to know what was that STRING argument to
search_command.  It should be a regular expression.

Do you have any unusual customizations related to message-mode?

bug#37575: 27.0.50; Segfault on redisplay

[Richard Copley]

[-- Attachment #1: Type: text/plain, Size: 2063 bytes --]

On Thu, 3 Oct 2019 at 18:03, Eli Zaretskii <eliz@gnu.org> wrote:

> [Private email?]
>
> From: Richard Copley <rcopley@gmail.com>
> > Date: Wed, 2 Oct 2019 20:28:40 +0100
> >
> >  Hmm... I don't see how re_match_2_internal on line 4940 could possibly
> >  cause a fatal signal,
> >
> > Taking the backtrace at face value, clearly d pointed to invalid memory.
>
> Theoretically, yes.  I very much doubt that, but it would be good to
> examine the value of d (which I guess we cannot now?).
>

That's right.


> >  and that .chkstk in the backtrace is a hint of
> >  some stack-related problem.
> >
> > I don't follow. The entry is after the signal was raised, not before.
> Calling chkstk doesn't indicate a problem.
>
> chkstk is the function that probes the stack for whether it crossed
> the guard page at the end of the stack (a.k.a "stack overflow").  It
> is invoked internally by alloca (except that there's no alloca
> anywhere in sight near the code that allegedly blew up), and when
> allocating stack-based data.


The chktsk call is in ntdll!RtlRaiseException.


>   However, note that it is chkstk that
> ended up in the exception handler, which is at least weird.  IME, this
> more often than not happens when the code longjmp's on the wrong
> stack, which is why I asked about other threads.
>

We're nowhere near any longjmp.

> And given that chkstk is a leaf function, how do you deduce anything from
> its presence, except that there is
> > some flaw in GDB's backtrace generation or in its debug information for
> ntdll.dll?
>
> I deduce that because there should be no reason for chkstk itself to
> crash.
>

Again, the crash is before the chkstk in the backtrace, not after it.


> >    If you still have this crashed
> >  sesion inside GDB, please show the result of
> >
> >    (gdb) thread apply all bt
> >
> > I don't have it now.
>
> That's too bad.  And I guess this is not reproducible, either?
>

Doesn't seem to be.


> > If it happens again I'll try and get that. (Something in
> font-lock-keywords-alist, I suppose.)
>
> OK.
>

OK.

[-- Attachment #2: Type: text/html, Size: 3807 bytes --]

bug#37575: 27.0.50; Segfault on redisplay

[Richard Copley]

[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]

On Thu, 3 Oct 2019 at 19:04, Richard Copley <rcopley@gmail.com> wrote:

> On Thu, 3 Oct 2019 at 18:03, Eli Zaretskii <eliz@gnu.org> wrote:
>
> chkstk is the function that probes the stack for whether it crossed
>> the guard page at the end of the stack (a.k.a "stack overflow").  It
>> is invoked internally by alloca (except that there's no alloca
>> anywhere in sight near the code that allegedly blew up), and when
>> allocating stack-based data.
>
>
> The chktsk call is in ntdll!RtlRaiseException.
>

From "objdump -Mintel -d -C -l c:\windows\system32\ntdll.dll":

   0x0000000180051f77 <ntdll!RtlRaiseException+615>: callq  0x1800a34c0
<ntdll!__chkstk>
[...]
   0x00000001800520a4 <ntdll!RtlRaiseException+916>: callq  0x1800a35d0
<ntdll!__chkstk+272>

  However, note that it is chkstk that
>> ended up in the exception handler, which is at least weird.  IME, this
>> more often than not happens when the code longjmp's on the wrong
>> stack, which is why I asked about other threads.
>>
>
> We're nowhere near any longjmp.
>
> > And given that chkstk is a leaf function, how do you deduce anything
>> from its presence, except that there is
>> > some flaw in GDB's backtrace generation or in its debug information for
>> ntdll.dll?
>>
>> I deduce that because there should be no reason for chkstk itself to
>> crash.
>>
>
It's the debug information that is incorrect. In the ntdll.dll on my
system, chkstk itself is 77 bytes long. (As you would expect, this
function's control flow is extremely simple to follow.) But 3392 bytes,
containing several blocks of code which are not reached from chkstk, are
attributed to chkstk in the debug information. None of those code blocks
crashed. One of them invoked the exception handler.

This is a straightforward backtrace, modulo the deficiencies that an
experienced low-level programmer learns to expect.  It says that
dereferencing d raised an access violation.

[-- Attachment #2: Type: text/html, Size: 3444 bytes --]

bug#37575: 27.0.50; Segfault on redisplay

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Thu, 3 Oct 2019 19:04:49 +0100
> 
> Again, the crash is before the chkstk in the backtrace, not after it.

It's both before and after, AFAICT.  Normally, when Emacs crashes due
to SIGSEGV, there's no chkstk on the callstack, not AFAIR.

As for longjmp: if another thread, whose stack was not shown, throws
to top-level (e.g., if it somehow calls Fsignal and its ilk), it will
longjmp to the wrong stack.  That's the situation I had in mind.

Anyway, I don't really understand where this discussion goes.  It is
purely academic, because all the evidence was unfortunately lost.  If
you want me to say I might be wrong with my guesses, here I am saying
that.

bug#37575: 27.0.50; Segfault on redisplay

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Thu, 3 Oct 2019 19:38:04 +0100
> 
> This is a straightforward backtrace, modulo the deficiencies that an experienced low-level programmer learns
> to expect.  It says that dereferencing d raised an access violation.

Then I guess I'm not experienced enough, and I should stop trying to
guess what caused this crash.

bug#37575: 27.0.50; Segfault on redisplay

[Richard Copley]

[-- Attachment #1: Type: text/plain, Size: 569 bytes --]

On Thu, 3 Oct 2019 at 19:58, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Richard Copley <rcopley@gmail.com>
> > Date: Thu, 3 Oct 2019 19:38:04 +0100
> >
> > This is a straightforward backtrace, modulo the deficiencies that an
> experienced low-level programmer learns
> > to expect.  It says that dereferencing d raised an access violation.
>
> Then I guess I'm not experienced enough, and I should stop trying to
> guess what caused this crash.
>

If that means you're going to stop bullying me about it, it's fine with me.

You're very welcome for the bug report.

[-- Attachment #2: Type: text/html, Size: 1099 bytes --]

bug#37575: 27.0.50; Segfault on redisplay

[Stefan Kangas]

Hi Richard,

Thank you for your bug report.

Richard Copley <rcopley@gmail.com> writes:

>  >    If you still have this crashed
>  >  sesion inside GDB, please show the result of
>  > 
>  >    (gdb) thread apply all bt
>  > 
>  > I don't have it now.
>
>  That's too bad.  And I guess this is not reproducible, either?
>
> Doesn't seem to be.
>  
>  > If it happens again I'll try and get that. (Something in font-lock-keywords-alist, I suppose.) 
>
>  OK.
>
> OK.

Have you seen this bug since?  IIUC, it seems like it will be hard to
make any progress here without more information or a way to reproduce
it.

Best regards,
Stefan Kangas

bug#37575: 27.0.50; Segfault on redisplay

[Richard Copley]

tags 37575 + unreproducible
close 37575
thanks

On Mon, 20 Jan 2020 at 19:07, Stefan Kangas <stefan@marxist.se> wrote:
> Thank you for your bug report.

That is much appreciated. Thank you.

> Have you seen this bug since?  IIUC, it seems like it will be hard to
> make any progress here without more information or a way to reproduce
> it.

One of life's little mysteries. I'm hereby tagging as unreproducible
and closing.

Best regards,
Richard.