bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#21965: 24.5; Emacs freezes when canceling at open file
Date: Tue, 24 Nov 2015 05:34:55 +0200

> From: John Wiegley <jwiegley@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  21965@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]