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: Maneesh Yadav <maneeshkyadav <at> gmail.com>
To: John Wiegley <jwiegley <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 14:51:57 -0800

FWIW I just triggered the condition 3 times in a row (I seem to be
getting better at triggering it), attached with lldb output
(backtraces looks the same as before as well).  Looks like the same
instruction?


#1



Process 25176 stopped

* thread #1: tid = 0x7369a, 0x00007fff8a861166
libsystem_kernel.dylib`__psynch_mutexwait + 10, queue =
'com.apple.main-thread', stop reason = signal SIGSTOP

    frame #0: 0x00007fff8a861166 libsystem_kernel.dylib`__psynch_mutexwait + 10

libsystem_kernel.dylib`__psynch_mutexwait:

->  0x7fff8a861166 <+10>: jae    0x7fff8a861170            ; <+20>

    0x7fff8a861168 <+12>: movq   %rax, %rdi

    0x7fff8a86116b <+15>: jmp    0x7fff8a85cc53            ; cerror_nocancel

    0x7fff8a861170 <+20>: retq


(lldb) thread backtrace

* thread #1: tid = 0x7369a, 0x00007fff8a861166
libsystem_kernel.dylib`__psynch_mutexwait + 10, queue =
'com.apple.main-thread', stop reason = signal SIGSTOP

  * frame #0: 0x00007fff8a861166 libsystem_kernel.dylib`__psynch_mutexwait + 10

    frame #1: 0x00007fff853b5696
libsystem_pthread.dylib`_pthread_mutex_lock + 480

    frame #2: 0x0000000100a17ba1 libglib-2.0.0.dylib`g_mutex_lock + 26

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

    frame #4: 0x000000010024fc47 emacs`xg_select + 231
...



#2

Process 25238 stopped

* thread #1: tid = 0x742be, 0x00007fff8a861166
libsystem_kernel.dylib`__psynch_mutexwait + 10, queue =
'com.apple.main-thread', stop reason = signal SIGSTOP

    frame #0: 0x00007fff8a861166 libsystem_kernel.dylib`__psynch_mutexwait + 10

libsystem_kernel.dylib`__psynch_mutexwait:

->  0x7fff8a861166 <+10>: jae    0x7fff8a861170            ; <+20>

    0x7fff8a861168 <+12>: movq   %rax, %rdi

    0x7fff8a86116b <+15>: jmp    0x7fff8a85cc53            ; cerror_nocancel

    0x7fff8a861170 <+20>: retq



#3

Process 25251 stopped

* thread #1: tid = 0x746f0, 0x00007fff8a861166
libsystem_kernel.dylib`__psynch_mutexwait + 10, queue =
'com.apple.main-thread', stop reason = signal SIGSTOP

    frame #0: 0x00007fff8a861166 libsystem_kernel.dylib`__psynch_mutexwait + 10

libsystem_kernel.dylib`__psynch_mutexwait:

->  0x7fff8a861166 <+10>: jae    0x7fff8a861170            ; <+20>

    0x7fff8a861168 <+12>: movq   %rax, %rdi

    0x7fff8a86116b <+15>: jmp    0x7fff8a85cc53            ; cerror_nocancel
    0x7fff8a861170 <+20>: retq


On Mon, Nov 23, 2015 at 7:39 PM, John Wiegley <jwiegley <at> gmail.com> wrote:
>>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> 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.
>
> Fair enough.  The docs for g_main_context_acquire do say that it should return
> immediately, if no other thread is holding the lock.
>
> John

Previous Next

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