GNU bug report logs - #21965
24.5; Emacs freezes when canceling at open file

Previous Next

Full log

View this message in rfc822 format

From: John Wiegley <jwiegley <at> gmail.com>
To: Maneesh Yadav <maneeshkyadav <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 21965 <at> debbugs.gnu.org
Subject: bug#21965: 24.5; Emacs freezes when canceling at open file
Date: Tue, 24 Nov 2015 17:38:06 -0800

>>>>> Maneesh Yadav <maneeshkyadav <at> gmail.com> writes:

> I still am uncomfortable with my comprehension of the lldb output but here
> is 'backtrace all' after triggering the condition

Ok! Now we know what the deadlock situation is:

Thread #2:

>     frame #3: 0x00000001009dd716 libglib-2.0.0.dylib`g_main_context_iteration + 55
...
>     frame #0: 0x00007fff8a8613fa libsystem_kernel.dylib`__select + 10

Thread #1:

>     frame #3: 0x00000001009db284 libglib-2.0.0.dylib`g_main_context_acquire + 42

It turns out that both g_main_context_acquire and g_main_context_iteration
(when called with NULL) call LOCK_CONTEXT on the "default context".

Now, I *think* the context should be different between these two threads: one
should be the default context, and one should be the worker context. But it
_looks_ like Thread #1 is being locked out by Thread #2.

In fact, reading the glib code, if the call to g_once_init_enter returns FALSE
within g_get_worker_context, then the worker context will be NULL! Which seems
like a subtle bug waiting to happen, and might be what's biting us.

To go deeper, we may need to build a separate copy of glib and start putting
some print statements in to find out why there is lock contention. Would you
be up for that? I'd like to know if this is happening in g_get_worker_context.

John

Previous Next

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