bug#14412: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> From: "Drew Adams" <drew....@oracle.com>
> Date: Thu, 16 May 2013 14:21:05 -0700
>
> Backtrace:
> 0x01159525
> 0x01159597
> 0x01001459
> 0x01021A5E
> 0x0101675C
> 0x010D82B4
> 0x010D938E
> 0x010D8F02
> 0x010116DA
> 0x010118DF
> 0x0101120C
> 0x01011326
> 0x01011365
> 0x01006765
> 0x010E4AC8
> 0x0101596C
> 0x01014E87
> 0x010E5146
> 0x01015511
> 0x01014E87
> 0x010E5146
> 0x0101596C
> 0x01014E87
> 0x010E5146
> 0x0101596C
> 0x01014E87
> 0x01013C70
> 0x010141D4
> 0x010E8FBA
> 0x01014B45
> 0x010E5146
> 0x01015511
> 0x01014E87
> 0x01014229
> 0x01024826
> 0x01010C39
> 0x01023814
> 0x01010696
> 0x010237CE
> 0x01022D88
> 0x010230B5
> 0x010029C4
> 0x010010F9
> 0x7C81776B

w32_backtrace at C:\Devel\emacs\repo\build\src/w32fns.c:7740
emacs_abort at C:\Devel\emacs\repo\build\src/w32fns.c:7772
terminate_due_to_signal at C:\Devel\emacs\repo\build\src/emacs.c:343
die at C:\Devel\emacs\repo\build\src/alloc.c:6522
unbind_to at C:\Devel\emacs\repo\build\src/eval.c:3124
Fprinc at C:\Devel\emacs\repo\build\src/print.c:658
print_error_message at C:\Devel\emacs\repo\build\src/print.c:901
Ferror_message_string at C:\Devel\emacs\repo\build\src/print.c:826
skip_debugger at C:\Devel\emacs\repo\build\src/eval.c:1566
maybe_call_debugger at C:\Devel\emacs\repo\build\src/eval.c:1607
Fsignal at C:\Devel\emacs\repo\build\src/eval.c:1431
xsignal at C:\Devel\emacs\repo\build\src/eval.c:1466
xsignal1 at C:\Devel\emacs\repo\build\src/eval.c:1481
Fsymbol_value at C:\Devel\emacs\repo\build\src/data.c:1061
exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:717
funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2906
Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2723
exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:900
funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2840
Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2723
exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:900
funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2906
Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2723
exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:900
funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2906
Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2723
Fapply at C:\Devel\emacs\repo\build\src/eval.c:2208
apply1 at C:\Devel\emacs\repo\build\src/eval.c:2442
Fcall_interactively at C:\Devel\emacs\repo\build\src/callint.c:381
Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2681
exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:900
funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2840
Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2723
call1 at C:\Devel\emacs\repo\build\src/eval.c:2468
command_loop_1 at C:\Devel\emacs\repo\build\src/keyboard.c:1578
internal_condition_case at C:\Devel\emacs\repo\build\src/eval.c:1193
command_loop_2 at C:\Devel\emacs\repo\build\src/keyboard.c:1167
internal_catch at C:\Devel\emacs\repo\build\src/eval.c:964
command_loop at C:\Devel\emacs\repo\build\src/keyboard.c:1146
recursive_edit_1 at C:\Devel\emacs\repo\build\src/keyboard.c:779
Frecursive_edit at C:\Devel\emacs\repo\build\src/keyboard.c:843
main at C:\Devel\emacs\repo\build\src/emacs.c:1531
?? at crt1.c:0

It aborts here:

/* If variable has a trivial value (no forwarding), we can
just set it. No need to check for constant symbols here,
since that was already done by specbind. */
>>> else if (XSYMBOL (this_binding.symbol)->redirect == SYMBOL_PLAINVAL)
SET_SYMBOL_VAL (XSYMBOL (this_binding.symbol),
this_binding.old_value);

Should we explicitly test for SYMBOLP before calling XSYMBOL?

[Lars Ingebrigtsen]

Eli Zaretskii <el...@gnu.org> writes:

> It aborts here:
>
> /* If variable has a trivial value (no forwarding), we can
> just set it. No need to check for constant symbols here,
> since that was already done by specbind. */
> >>> else if (XSYMBOL (this_binding.symbol)->redirect == SYMBOL_PLAINVAL)
> SET_SYMBOL_VAL (XSYMBOL (this_binding.symbol),
> this_binding.old_value);
>
> Should we explicitly test for SYMBOLP before calling XSYMBOL?

Was this resolved, by any chance?

--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no

[Eli Zaretskii]

> From: Lars Ingebrigtsen <la...@gnus.org>
> Cc: Drew Adams <drew....@oracle.com>, 14...@debbugs.gnu.org
> Date: Sat, 26 Dec 2015 01:47:50 +0100

>
> Eli Zaretskii <el...@gnu.org> writes:
>
> > It aborts here:
> >
> > /* If variable has a trivial value (no forwarding), we can
> > just set it. No need to check for constant symbols here,
> > since that was already done by specbind. */
> > >>> else if (XSYMBOL (this_binding.symbol)->redirect == SYMBOL_PLAINVAL)
> > SET_SYMBOL_VAL (XSYMBOL (this_binding.symbol),
> > this_binding.old_value);
> >
> > Should we explicitly test for SYMBOLP before calling XSYMBOL?
>
> Was this resolved, by any chance?

Not that I could see, but adding the test is trivial, so I will do it
soon.

[Eli Zaretskii]

> Date: Sat, 26 Dec 2015 12:07:19 +0200
> From: Eli Zaretskii <el...@gnu.org>
> Cc: 14...@debbugs.gnu.org

Done.

[Paul Eggert]

Eli, thanks for fixing that. There's parallel code in backtrace_eval_unrewind
that presumably should be fixed in a similar way. Also, it's clearer to keep the
FALLTHROUGH!! comment at the actual fallthrough point. I installed the attached
additional patch to try to address these issues.