GNU bug report logs - #52295
windows 98: Killing text results in coding system complaint

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: luangruo <at> yahoo.com
Cc: 52295 <at> debbugs.gnu.org
Subject: Re: bug#52295: 28.0.90;
 Killing text results in coding system complaint
Date: Sat, 18 Dec 2021 20:30:08 +0200

> Date: Sat, 18 Dec 2021 08:48:07 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 52295 <at> debbugs.gnu.org
> 
> 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.

Btw, there's one more alternative: to debug Emacs on Windows 9X
remotely, via gdbserver.  Did you try that?  The advantage is that
gdbserver is a much smaller and simpler program, so chances are it
will be able to run on Windows 9X.  GDB itself will run on a different
system (could even be GNU/Linux, if you have GDB that was built to
support debugging Windows PE executables), where all the problems of
running a modern GDB don't exist.  You just need the target system to
be connected to a network, so that GDB and gdbserver could
communicate.

Previous Next

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