GNU bug report logs - #30182
27.0.50; Crash when doing mouse-over on modeline

Previous Next

Package: emacs;

Reported by: Sujith <m.sujith <at> gmail.com>

Date: Sat, 20 Jan 2018 06:27:02 UTC

Severity: normal

Found in version 27.0.50

Done: martin rudalics <rudalics <at> gmx.at>

Bug is archived. No further changes may be made.

Full log


Message #173 received at 30182 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org
Subject: Re: bug#30182: Update
Date: Fri, 02 Feb 2018 18:00:49 +0200
> Date: Fri, 02 Feb 2018 09:28:18 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org
> 
>  > "Asynchronous redisplay" could only mean the call to expose_frame, is
>  > that right?
> 
> That's what I meant, yes.

Actually, mouse movement could also cause that, via the MotionNotify
event that calls note_mouse_highlight.  Right?

> note_mouse_highlight calls note_mode_line_or_margin_highlight which
> does
> 
> 		  help_echo_string = (FUNCTIONP (default_help)
> 				      ? safe_call1 (default_help, window)
> 				      : default_help);

Does this mean we can now actually call Lisp asynchronously upon every
mouse movement?  That's a definite no-no.

> We could instrument the code around this to do something special when
> Vtimer_check_in_progress is non-nil.

We could bind inhibit-eval-during-redisplay to a non-nil value.
However, that will disable your function, and defeat the whole purpose
of making mode-line-default-help-echo a function.

But I think the problem introduced by this recent change, which allows
Lisp to be called asynchronously, is a much more serious problem than
just timer_check.  We _cannot_ call Lisp asynchronously in any safe
way.  I'm afraid we will have to roll back the change which allowed
mode-line-default-help-echo to be a function.  Can you find an
alternative way of achieving the same effect, that doesn't call Lisp
from note_mode_line_or_margin_highlight?

I think we should introduce some protection against making such
implementation mistakes in the future.  Like some flag that we set
when redisplay is entered asynchronously, and that is checked in
safe__call, where we'd signal an error (or maybe even abort, under
"--enable-checking") if the flag is set.  This should allow us to find
such problems much faster.  WDYT?




This bug report was last modified 7 years and 108 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.