GNU bug report logs - #25172
26.0.50; Concurrency feature, sit-for doesn't work (crashing and unexpected behaviour)

Previous Next

Full log

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

From: Elias Mårtenson <lokedhs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 25172 <at> debbugs.gnu.org,
 Clément Pit--Claudel <clement.pit <at> gmail.com>
Subject: Re: bug#25172: 26.0.50; Concurrency feature, sit-for doesn't work
 (crashing and unexpected behaviour)
Date: Fri, 16 Dec 2016 00:28:03 +0800

[Message part 1 (text/plain, inline)]

On 16 Dec 2016 12:24 am, "Eli Zaretskii" <eliz <at> gnu.org> wrote:

> From: Elias Mårtenson <lokedhs <at> gmail.com>
> Date: Thu, 15 Dec 2016 11:30:54 +0800
> Cc: Clément Pit--Claudel <clement.pit <at> gmail.com>,
>       25172 <at> debbugs.gnu.org
>
>  After applying that patch, it hasn't crashed yet. So either it fixes the
problem, or it's simply buch harder to
>  reproduce. So far so good. Thanks a lot!
>
> I want to note that the thing that seems to fix it is the application of
the most recent suggestion.

Thanks, I pushed it now.

> In other words, if I roll back the application of the previous
> suggestion (removing the calls to clock_input ()/unblock_input()) it
> still seems to be stable.

Yes, it turns out acquiring Glib context is thread-safe (it uses a
mutex internally), so only one thread can ever acquire it.  Not
calling Glib functions when we failed to acquire context avoids both
the crashes in Glib and calling block_input/unblock_input from more
than one thread.

I guess we can now close this bug?


Yes, I think so.


Thanks so much for your help in debugging this.


I'm happy it was resolved. ☺️

[Message part 2 (text/html, inline)]

Previous Next

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