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


View this message in rfc822 format

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: bug#30182: Update
Date: Sat, 03 Feb 2018 10:03:57 +0100
> 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.

This recent change was only an amendment to a fix of Bug#16647.  There
I changed the shape of the mouse cursor, here the accompanying
tooltip.  So anything that goes wrong now should have gone wrong then
already.

But for one thing: The present changed introduced that call to
`window-in-direction' which clearly is a bad idea for the mode line
because it may want to get the height of the mode line while building
the mode line string and thus introduce infinite recursion.  I don't
know why that didn't happen here in the first place.  For the
interested - try to display the value returned by (posn-at-point) in
the mode line.

> 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 could do that easily.  But IMO the problem is not with calling Lisp
per se.  We frequently call Lisp fnctions from C.  The problem is with
altering the global state (`timer-list' being part of that) IIUC.

> 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?

I'd need to see the problem identified first.  The comment in xdisp.c
says that

   Under window systems
   like X, some portions of the redisplay code are also called
   asynchronously during mouse movement or expose events.  It is very
   important that these code parts do NOT use the C library (malloc,
   free) because many C libraries under Unix are not reentrant.  They
   may also NOT call functions of the Lisp interpreter which could
   change the interpreter's state.

What is an "asynchronous call" and how can I identify it?  How do I
avoid using the C library?  How do I avoid calling functions of the
Lisp interpreter?

And one thing that is obviously needed is some guidance on what should
be allowed in the mode line and what should be avoided.  For example,
having `mode-line-buffer-identification' install a timer is something
that should be avoided IMO.

martin




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.