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

[Maneesh Yadav]

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@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@gmail.com> wrote:
>>>>>>> Eli Zaretskii <eliz@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