bug#14861: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 14 Jul 2013 23:21:07 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 14861@debbugs.gnu.org
> 
> Translation:
> 
>   w32_backtrace at w32fns.c:7757
>   emacs_abort at w32fns.c:7789
>   terminate_due_to_signal at emacs.c:350
>   die at alloc.c:6532
>   unwind_create_frame at w32fns.c:4225
>   unbind_to at eval.c:3210
>   unwind_to_catch at eval.c:1105
>   Fthrow at eval.c:1132
>   Ftop_level at keyboard.c:1203
>   Ffuncall at eval.c:2787
>   exec_byte_code at bytecode.c:903
>   funcall_lambda at eval.c:3024
>   Ffuncall at eval.c:2839
>   apply1 at eval.c:2556
>   Fcall_interactively at callint.c:381
>   Ffuncall at eval.c:2797
>   exec_byte_code at bytecode.c:903
>   funcall_lambda at eval.c:2958
>   Ffuncall at eval.c:2839
>   call1 at eval.c:2589
>   command_loop_1 at keyboard.c:1575
>   internal_condition_case at eval.c:1289
>   command_loop_2 at keyboard.c:1164
>   internal_catch at eval.c:1063
>   command_loop at keyboard.c:1135
>   recursive_edit_1 at keyboard.c:776
>   Frecursive_edit at keyboard.c:840
>   Ffuncall at eval.c:2787
>   exec_byte_code at bytecode.c:903
>   funcall_lambda at eval.c:2958
>   Ffuncall at eval.c:2839
>   Fapply at eval.c:2329
>   apply1 at eval.c:2563
>   call_debugger at eval.c:322
>   maybe_call_debugger at eval.c:1703
>   Fsignal at eval.c:1523
>   Ffuncall at eval.c:2793

Thanks.

This crash is not interesting.  As I see it, some Lisp code called
signal, which entered the debugger, which I presume created a new
frame, and then died because of an obscure assertion violation when
the frame was deleted.  Debugger launched in separate frames is known
to do that, and no one ever cared.

Closing.