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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: John Wiegley <jwiegley <at> gmail.com>
Cc: maneeshkyadav <at> gmail.com, 21965 <at> debbugs.gnu.org
Subject: Re: bug#21965: 24.5; Emacs freezes when canceling at open file
Date: Tue, 24 Nov 2015 05:34:55 +0200

> From: John Wiegley <jwiegley <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  21965 <at> debbugs.gnu.org
> Date: Mon, 23 Nov 2015 14:17:17 -0800
> 
> We're still missing file and line numbers for the Emacs code, which is odd.
> But not terribly important, since the lockup is happening inside glib, it
> appears.
> 
> >     frame #3: 0x00000001009db284
> >     libglib-2.0.0.dylib`g_main_context_acquire + 42
> 
> So, here's that function, more or less:
> 
>     gboolean 
>     g_main_context_acquire (GMainContext *context)
>     {
>       gboolean result = FALSE;
>       GThread *self = G_THREAD_SELF;
>     
>       if (context == NULL)
>         context = g_main_context_default ();
>       
>       LOCK_CONTEXT (context);
>       /* ... */
>     }
> 
> We're blocked waiting on the context. The question then being: who else has
> that context? Is it another Emacs thread?
> 
> Eli, does this ring any bells?

No.  And I'm not even convinced that's where we are blocked.  It could
be that this is part of a loop that Emacs is waiting in.  To prove
that we are blocked there, one needs to attach the debugger many times
and see that the debugger finds Emacs at _exactly_ the same
instruction.  Or, after attaching, step Emacs and see that it cannot
move even a single instructions.

If this is really what happens, and Emacs cannot acquire a mutex, that
would mean someone is holding that mutex, and the question is who that
someone is.

Previous Next

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