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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org
Subject: Re: bug#30182: Update
Date: Wed, 24 Jan 2018 21:13:50 +0200

> Date: Wed, 24 Jan 2018 09:39:38 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org
> 
>  >> 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?

How else can a data structure change while the main thread is running
code that doesn't modify the data structure?

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

atimers and timers are two very different creatures, and I don't think
I see how atimers could be relevant to our issue.  If you do, please
tell what I'm missing in this picture.

Previous Next

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