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 #50 received at 30182 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, Sujith <m.sujith <at> gmail.com>
Cc: 30182 <at> debbugs.gnu.org
Subject: Re: bug#30182: Update
Date: Mon, 22 Jan 2018 19:59:28 +0100
[Message part 1 (text/plain, inline)]
> The above list has 5 elements, not 4.

Wouldn't that imply that a timer was added after `copy-sequence'
started?

> Martin, did you try reproducing this on your GNU/Linux box?  Did you
> succeed?

So far I have condensed a ~50 lines excerpt from w3m.el which should
include all necessary ingredients to shorten the mode line text as w3m
does, but to no avail.

> 	    /* Only DX and DY have changed.  */
> 	    tip_f = XFRAME (tip_frame);
> 	    if (!NILP (tip_timer))
> 	      {
>    -             Lisp_Object timer = tip_timer;
>    -
>    +             call1 (Qcancel_timer, tip_timer);
> 		tip_timer = Qnil;
>    -             call1 (Qcancel_timer, timer);
> 	      }
>
> 	    block_input ();
>
> Note that the old code copied the tip timer, then nullified it, and
> then canceled it using the copy.  While the new code cancels first and
> then nullifies.

So that code really had some purpose?  OTOH why would someone had
bothered to write it in the first place.  And if that someone was
Gerd, he probably had enough prior experience with timer variables to
put it there.  Sujith, can you try the attached patch?

> The crash seems to be caused by an element of timer-list becoming nil
> somehow.  We need to understand how that happens.  The relevant
> players are (1) the fact that w3m.el schedules a timer from a
> mode-line's :eval form, and (2) the tool-tip machinery, in particular
> its canceling timer.  And it sounds like by the time copy-sequence
> runs and tries to copy timer-list, the damage to the list is already
> done.  Also, an important thing to remember is that copy-sequence
> copies the list, but doesn't copy the elements, so the elements are
> shared with the original list.  Hmm...

The list with the 5 timers seems pretty innocuous to me.  I still
wonder why concat decided to reserve only 4 elements for its copy.

martin
[xfns.c.diff (text/plain, attachment)]

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.