bug#52295: 28.0.90; Killing text results in coding system complaint

[Eli Zaretskii <eliz@gnu.org>]

> From: Po Lu <luangruo@yahoo.com>
> Cc: 52295@debbugs.gnu.org
> Date: Sat, 18 Dec 2021 08:29:21 +0800
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> > I will build a pdumper build with all the usual debug options and see
> > what comes up.
> 
> An unoptimized pdumper build with CFLAGS='-O0'
> --enable-checking="yes,glyphs" crashes when a dump file is present, so
> there is definitely more here than meets the eye, but I have no idea how
> to get a working debugger onto that Windows 9x system.
> 
> Is there some way to save a core dump (or backtrace) there for debugging
> on a more recent MS-Windows machine?

Is this a real crash (segfault), or an abort where we pop up the Emacs
Abort dialog?  Since you compiled with --enable-checking, I think it's
the latter.

If it's a real crash, you could use the Windows Event log to find out
the address where it crashes, and then use GDB on another system to
see where that address is in the sources (but the address printed by
Windows needs to be "translated" into addresses that you submit to GDB
by adding some constant, AFAIR).

The other alternative is to insert many fprintf's to stderr into the
sources, and use that to determine where it crashes.

If it's an abort, then saying NO to the dialog will produce an
emacs_backtrace.txt file with addresses of the backtrace, which you
could take to another Windows system and use addr2line (from Binutils)
to recover the file names, function names, and line numbers that
correspond to the addresses; see the node "Crashing" in the Emacs
manual for how to do that.