[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs hangs enabling debug-on-error
From: |
Kim F. Storm |
Subject: |
Re: Emacs hangs enabling debug-on-error |
Date: |
19 May 2004 13:32:34 +0200 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 |
Richard Stallman <address@hidden> writes:
> > The problem is that redisplay triggers an error which throws to
> > top-level while input is blocked, and we don't unblock input in that
> > case.
>
> I have just installed a fix for this (in recursive-edit and top-level).
>
> Would you please show me this change?
In recursive-edit, the fix is to exit immediately if input is blocked
(to prevent the resulting lock-up).
The change to top-level is basically to unblock input (in a sensible
way) if it was blocked on entry.
I agree that these measures do not fix the original problem -- but IMO
they make sense as general way to prevent hangs in "odd cases".
>
> That may not entirely fix the bug. It may be a bug just to run LIsp
> code in the middle of updating non-Lisp data structures, such as
> occurs in the toolbar code. So even if your change is an improvement,
> we probably need to fix the code in xdisp.c as well.
>
The problem is not that lisp code is run at that point (it works nicely).
The problem is that when GTK support was added, Jan D. added BLOCK_INPUT
around the tool-bar building code to avoid GTK acessing the (incomplete)
tool-bar data structures.
Now, if there is an error in the lisp code that constructs the
tool-bar, and debug-on-error is enabled, the debugger is entered with
blocked input, and emacs hangs.
A possible fix (for GTK) could be to work on a separate data structure
and move it into place when it is ready (as an atomic operation); then
the BLOCK_INPUT is not needed.
The problem as I see it, is that the function which builds the
tool-bar (tool_bar_items) receives the existing tool-bar data as a
parameter, so it is unclear whether the update is performed "in-situ"
or not.
If you want to improve further on this, please do so.
To summarize:
Test case:
----------
Start emacs -q (from before my patch), and then evaluate the following:
(setq debug-on-error t)
(define-key tool-bar-map [tt-exit]
'(menu-item
"TEST"
vm-toolbar-next-command
:enable (vm-toolbar-any-messages-p)
:button (:toggle nil)
:image (image :type xpm :mask heuristic :file "../lisp/toolbar/alias.xpm")))
ChangeLog
---------
2003-04-23 Jan Djärv <address@hidden>
* xdisp.c (update_tool_bar): BLOCK_INPUT before calling
tool_bar_items so GTK tool bar expose callback does not access items
being updated.
Diff:
-----
*** xdisp.c 16 Apr 2003 05:09:36 -0000 1.826
--- xdisp.c 23 Apr 2003 17:51:33 -0000 1.827
***************
*** 8152,8159 ****
--- 8152,8161 ----
GCPRO1 (old_tool_bar);
/* Build desired tool-bar items from keymaps. */
+ BLOCK_INPUT;
f->tool_bar_items
= tool_bar_items (f->tool_bar_items, &f->n_tool_bar_items);
+ UNBLOCK_INPUT;
/* Redisplay the tool-bar if we changed it. */
if (! NILP (Fequal (old_tool_bar, f->tool_bar_items)))
--
Kim F. Storm http://www.cua.dk
- Re: Emacs hangs enabling debug-on-error, (continued)
- Re: Emacs hangs enabling debug-on-error, Robert Mecklenburg, 2004/05/03
- Re: Emacs hangs enabling debug-on-error, Kim F. Storm, 2004/05/04
- Re: Emacs hangs enabling debug-on-error, Robert Mecklenburg, 2004/05/04
- Re: Emacs hangs enabling debug-on-error, Kim F. Storm, 2004/05/05
- Re: Emacs hangs enabling debug-on-error, Kim F. Storm, 2004/05/13
- Re: Emacs hangs enabling debug-on-error, Richard Stallman, 2004/05/14
- Re: Emacs hangs enabling debug-on-error, Kim F. Storm, 2004/05/14
- Re: Emacs hangs enabling debug-on-error, Richard Stallman, 2004/05/16
- Re: Emacs hangs enabling debug-on-error, Kim F. Storm, 2004/05/17
- Re: Emacs hangs enabling debug-on-error, Richard Stallman, 2004/05/18
- Re: Emacs hangs enabling debug-on-error,
Kim F. Storm <=
- Re: Emacs hangs enabling debug-on-error, Richard Stallman, 2004/05/20
Re: Emacs hangs enabling debug-on-error, Richard Stallman, 2004/05/04
Re: Emacs hangs enabling debug-on-error, Richard Stallman, 2004/05/02