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: Wed, 24 Jan 2018 09:39:38 +0100

>> We don't know whether `timer-list' had actually 5 elements when
>> running the above code.
>
> If it didn't, then the 5th element could have only been added by
> another thread.

Why another thread?

> Is that possible?  This is a GTK build with system
> tooltips, right?  And even in such a configuration the tooltips are
> popped up in the context of the main thread, is that so?  So how could
> the list be modified while copy-sequence runs?
>
>> And Fmake_list can rarely_quit.
>
> Not sure how quitting in Fmake_list could explain anything.  If it
> quits, it just throws to top-level, and that's all, right?

Fmake_list does

  for (EMACS_INT size = XFASTINT (length); 0 < size; size--)
    {
      val = Fcons (init, val);
      rarely_quit (size);
    }

so IIUC rarely_quit is eventually called with size zero.  Now we have

rarely_quit (unsigned short int count)
{
  if (! count)
    maybe_quit ();

which, if count is zero, calls maybe_quit which according to

  if (!NILP (Vquit_flag) && NILP (Vinhibit_quit))
    process_quit_flag ();
  else if (pending_signals)
    process_pending_signals ();

may call process_pending_signals which does

  do_pending_atimers ();

which may eventually do a schedule_atimer.

So IMHO the problem is not that rarely_quit "just throws to top-level"
but might add a timer on the fly while the timer list is copied.

martin

Previous Next

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