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

Previous Next

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: Sun, 04 Feb 2018 11:01:03 +0100

> That commentary was outdated.  I updated it now.

Thanks.

> Please take a look
> and tell if anything there needs clarification or any other change.

One question I'd ask myself is how we avoid that redisplay is
reentered during maybe_quit.  And I would like to know which settings
can disrupt redisplay and whether and which, if any, parts of
redisplay (mode lines and echo area) may get through after such a
disruption, probably to avoid garbling the display.

> I believe that what I wrote in the message to which you were replying
> was based on incorrect interpretation of what actually happens.  With
> the correct interpretation, there's no asynchronous entry into
> redisplay, if "asynchronous" is interpreted literally.  So the
> measures I described above are unnecessary, but there is a need to
> block input around C fragments that cannot tolerate changes in global
> state.

I must admit that I never thought of maybe_quit being able to process
input when a function like 'copy-sequence' executes "normally".  Maybe
this should be emphasized in the Elisp manual's section on Quitting.
I don't even understand what it's good for to process input just after
a few conses or calculating the length of some short list.

> This now raises the question: should we block input around the 2 calls
> to Fcopy_sequence in timer_check, on the emacs-26 branch?  I tend to
> think we should, because letting arbitrary Lisp change the timer lists
> while Fcopy_sequence runs could cause hard-to-debug bugs.  WDYT?

It cannot possibly harm so I think we should.

>> 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.
>
> If we protect Fcopy_sequence as indicated above, I think such a
> limitation would no longer be necessary.

If the :eval form in 'mode-line-format' changes an arbitrary list
which is about to be copied, a similar crash could be provoked.  Or am
I missing something?

martin

Previous Next

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