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

[Maneesh Yadav]

A disconcerting finding: I could not replicate the bug while briefly
commandeering a colleague's machine (a mac which I installed macports
emacs onto).

I still am uncomfortable with my comprehension of the lldb output but
here is 'backtrace all' after triggering the condition

(lldb) thread backtrace all

* thread #1: tid = 0x7d73b, 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


  thread #2: tid = 0x7d73c, 0x00007fff8a8613fa
libsystem_kernel.dylib`__select + 10, name = 'gmain'

    frame #0: 0x00007fff8a8613fa libsystem_kernel.dylib`__select + 10

    frame #1: 0x00000001009e8aef libglib-2.0.0.dylib`g_poll + 399

    frame #2: 0x00000001009dd667
libglib-2.0.0.dylib`g_main_context_iterate + 326

    frame #3: 0x00000001009dd716
libglib-2.0.0.dylib`g_main_context_iteration + 55

    frame #4: 0x00000001009de809 libglib-2.0.0.dylib`glib_worker_main + 53

    frame #5: 0x00000001009fdcdb libglib-2.0.0.dylib`g_thread_proxy + 90

    frame #6: 0x00007fff853b805a libsystem_pthread.dylib`_pthread_body + 131

    frame #7: 0x00007fff853b7fd7 libsystem_pthread.dylib`_pthread_start + 176

    frame #8: 0x00007fff853b53ed libsystem_pthread.dylib`thread_start + 13

On Tue, Nov 24, 2015 at 5:02 PM, John Wiegley <jwiegley@gmail.com> wrote:
>>>>>> Maneesh Yadav <maneeshkyadav@gmail.com> writes:
>
>> lldb "thread continue" runs after, but emacs remains unresponsive 'thread
>> step-in" does increment the instruction counter (output below)...but not
>> really sure what that implies.
>
> Maneesh,
>
> Can you show me the full backtrace of all threads when it deadlocks? I just
> realized that xg_select is called from wait_reading_process_output, which I
> believe means it's callable from multiple threads at once.
>
> The behavior of g_main_context_acquire is *documented* to never block, but
> rather to return FALSE if another thread has the context; if the behavior has
> been changed to block on OS X -- and the thread with the context is calling
> pselect() and waiting to return -- this would match your experience.
>
> John