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: 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: bug#30182: Update
Date: Tue, 23 Jan 2018 21:59:32 +0200

> Date: Tue, 23 Jan 2018 19:44:53 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 30182 <at> debbugs.gnu.org
> 
>  > So the question now becomes: how come this code:
>  >
>  >    result_len_byte = 0;
>  >    result_len = 0;
>  >    some_multibyte = 0;
>  >    for (argnum = 0; argnum < nargs; argnum++)
>  >      {
>  >        EMACS_INT len;
>  >        this = args[argnum];
>  >        len = XFASTINT (Flength (this));
>  >        ...
>  >      }
>  >    result_len += len;
>  >
>  > (nargs = 1 in this case) produces result_len of 4, when timer-list has
>  > actually 5 elements?  Martin, any ideas?
> 
> Been there all the time.  That's why I earlier asked
> 
>    Wouldn't that imply that a timer was added after `copy-sequence'
>    started?
> 
> 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.  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?

Previous Next

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