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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Elias Mårtenson <lokedhs <at> gmail.com>
Cc: 25172 <at> debbugs.gnu.org, clement.pit <at> gmail.com
Subject: bug#25172: 26.0.50; Concurrency feature, sit-for doesn't work (crashing and unexpected behaviour)
Date: Thu, 15 Dec 2016 18:22:58 +0200

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

Thanks so much for your help in debugging this.

Previous Next

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