GNU bug report logs -
#21965
24.5; Emacs freezes when canceling at open file
Previous Next
Reported by: Maneesh Yadav <maneeshkyadav <at> gmail.com>
Date: Fri, 20 Nov 2015 21:21:02 UTC
Severity: normal
Found in version 24.5
Done: Stefan Kangas <stefan <at> marxist.se>
Bug is archived. No further changes may be made.
Full log
Message #47 received at 21965 <at> debbugs.gnu.org (full text, mbox):
Flog me if I am not doing this right. Seems that +debug on macports
is the easy to make debug compiles (an old thread seemed to suggest
that macports rejected this idea...but I guess it was eventually
accepted). So installed emacs +debug and reproduced the crash,
attached to emacs via lldb and got this backtrace (which looks a lot
like the previous, can I provide better info somehow?):
(lldb) process attach --name emacs
Process 23166 stopped
* thread #1: tid = 0x4d18b, 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
Executable module set to "/opt/local/bin/emacs".
Architecture set to: x86_64h-apple-macosx.
(lldb) thread backtrace
* thread #1: tid = 0x4d18b, 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
frame #5: 0x0000000100225c3d emacs`wait_reading_process_output + 3757
frame #6: 0x0000000100008cb6 emacs`sit_for + 582
frame #7: 0x0000000100108f00 emacs`read_char + 4496
frame #8: 0x0000000100104edd emacs`read_key_sequence + 1757
frame #9: 0x0000000100103cec emacs`command_loop_1 + 1212
frame #10: 0x00000001001bf04e emacs`internal_condition_case + 382
frame #11: 0x000000010011ce09 emacs`command_loop_2 + 41
frame #12: 0x00000001001be696 emacs`internal_catch + 342
frame #13: 0x0000000100102ddb emacs`command_loop + 187
frame #14: 0x0000000100102c9f emacs`recursive_edit_1 + 127
frame #15: 0x0000000100102f87 emacs`Frecursive_edit + 327
frame #16: 0x0000000100100fd3 emacs`main + 4387
frame #17: 0x00007fff8707a5c9 libdyld.dylib`start + 1
frame #18: 0x00007fff8707a5c9 libdyld.dylib`start + 1
On Sat, Nov 21, 2015 at 9:15 PM, Maneesh Yadav <maneeshkyadav <at> gmail.com> wrote:
> The trace is what what I saw after I sent pkill -USR2 emacs, I don't
> know quite know how to read it (other than the vague references to
> mutexs...no idea if that is actually relevant). Still trying to
> figure out how to get macports to compile debug emacs...hopefully will
> figure it out this w/e.
>
> On Sat, Nov 21, 2015 at 9:11 PM, John Wiegley <jwiegley <at> gmail.com> wrote:
>>>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>>> 7 libglib-2.0.0.dylib 0x0000000100888ba1 g_mutex_lock + 26
>>>> 8 libglib-2.0.0.dylib 0x000000010084c284 g_main_context_acquire + 42
>>>> 9 emacs 0x00000001001447cc xg_select + 135
>>>> 10 emacs 0x000000010012dbe2 wait_reading_process_output + 2074
>>>> 11 emacs 0x00000001000075b5 sit_for + 260
>>>> 12 emacs 0x000000010008be56 read_char + 5024
>>>> 13 emacs 0x000000010008918c read_key_sequence + 1526
>>
>>> This backtrace simply says that Emacs called 'abort'. And it did so
>>> because the user told it so.
>>
>> It might also be saying that Emacs deadlocked trying to obtain a mutex.
>>
>> John
This bug report was last modified 4 years and 267 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.