emacs-pretest-bug
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]