Re: Emacs - MinGW32 on W2K

[Eli Zaretskii]

> From: "Dhruva Krishnamurthy" <address@hidden>
> Date: Wed, 26 Feb 2003 15:24:24 +0530
> > 
> > Can you run Emacs under GDB and post here the C-level and Lisp-level
> > backtraces at the point of the crash?
> 
> This is the backtrace I have:
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x77fa018d in ?? ()
> (gdb) bt
> #0  0x77fa018d in ?? ()
> #1  0x0101f9b9 in funcall_lambda (fun=1099717760, nargs=12,
>     arg_vector=0x82f3c4) at eval.c:2927
> #2  0x0101f45d in Ffuncall (nargs=13, args=0x82f3c0) at eval.c:2797
> #3  0x010f4a91 in Fbyte_code (bytestr=830611668, vector=1101934848,
>     maxdepth=14) at bytecode.c:709
> #4  0x0101f9b9 in funcall_lambda (fun=1099044736, nargs=1,
> arg_vector=0x82f51c)
>     at eval.c:2927

Thanks.  This is a good start.

SIGTRAP usually means some major snafu, since that signal normally
happens only when the debugger sets a breakpoint at some place.
However, if GDB indeed set a breakpoint, it will expect a SIGTRAP at
that address, and will not announce a SIGTRAP, but rather say that
Emacs has hit a breakpoint.

So something strange is going on here, like stack overflow or maybe
Emacs somehow jumps to a bad address and tries to execute what is not
an executable code at all.

In cases such as this one, when the C-level backtrace starts from
command_loop_1 and proceeds with a series of Ffuncall's, call1's and
Fbyte_code's, it is most important to have a Lisp-level backtrace as
well.  To get that, make sure you invoke GDB from the `src' directory
of the Emacs source tree (where there'sa `.gdbinit' file that GDB will
read automatically), and then, when you get Emacs to crash with
SIGTRAP, type "xbacktrace" at the GDB prompt.  Then post the results
here.

Thanks for working on this.