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

Previous Next

Full log

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org
Subject: Re: bug#30182: Update
Date: Fri, 02 Feb 2018 09:28:18 +0100

> "Asynchronous redisplay" could only mean the call to expose_frame, is
> that right?

That's what I meant, yes.

> I'm not aware of any other asynchronous entry to
> redisplay.  We could call expose_frame asynchronously if a mouse
> movement caused the SIGIO signal be delivered to Emacs while
> copy-sequence did its job.  The SIGIO handler then could call
> gobble_input, which would read the X events from the socket, see the
> Expose event and call expose_frame, or see the MotionNotify event and
> call note_mouse_highlight.  However, neither of these is supposed to
> call Lisp, or evaluate the mode-line format (which would call Lisp via
> :eval), or at least I couldn't see any such call.  Both expose_frame
> and note_mouse_highlight just redraw the glyphs that are already
> computed by the previous redisplay cycle.

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);

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

> So I'm still unsure what is going on here.  But if indeed the above
> scenario somehow ends up calling Lisp from the async redisplay,
> wrapping the call to Fcopy_sequence in timer_check with block_input
> and unblock_input should solve the problem, right?

But we can't do that, right?  Users should be able to cancel it.

martin

Previous Next

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