bug#21965: 24.5; Emacs freezes when canceling at open file

[Maneesh Yadav]

For sure...let me make sure I can insert print statements into glib in
the context of my macports install (and get a little better
understanding of the glib event loop). Will write back once that is
up.


On Tue, Nov 24, 2015 at 5:38 PM, John Wiegley <jwiegley@gmail.com> wrote:
>>>>>> Maneesh Yadav <maneeshkyadav@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