From: Maneesh Yadav <maneeshkyadav@gmail.com>
To: John Wiegley <jwiegley@gmail.com>
Cc: 21965@debbugs.gnu.org
Subject: bug#21965: 24.5; Emacs freezes when canceling at open file
Date: Tue, 24 Nov 2015 17:15:10 -0800 [thread overview]
Message-ID: <CAPsivR8bVdaEdHoRvk05HOmm=SLZwPFM7ZjZcvwNwPkCAq9i5w@mail.gmail.com> (raw)
In-Reply-To: <m2h9kalwlg.fsf@newartisans.com>
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
next prev parent reply other threads:[~2015-11-25 1:15 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-20 19:18 bug#21965: 24.5; Emacs freezes when canceling at open file Maneesh Yadav
2015-11-20 21:37 ` John Wiegley
2015-11-20 21:47 ` Maneesh Yadav
2015-11-20 21:55 ` John Wiegley
2015-11-20 22:07 ` Maneesh Yadav
2015-11-20 22:45 ` Maneesh Yadav
2015-11-20 23:26 ` John Wiegley
2015-11-20 23:32 ` Maneesh Yadav
2015-11-20 23:54 ` John Wiegley
2015-11-21 1:46 ` Maneesh Yadav
2015-11-21 7:29 ` Eli Zaretskii
2015-11-22 5:11 ` John Wiegley
2015-11-22 5:15 ` Maneesh Yadav
2015-11-23 21:29 ` Maneesh Yadav
2015-11-23 22:17 ` John Wiegley
2015-11-24 0:30 ` Maneesh Yadav
2015-11-24 3:39 ` Eli Zaretskii
2015-11-24 3:34 ` Eli Zaretskii
2015-11-24 3:39 ` John Wiegley
2015-11-24 22:51 ` Maneesh Yadav
2015-11-24 22:58 ` Maneesh Yadav
2015-11-25 1:02 ` John Wiegley
2015-11-25 1:15 ` Maneesh Yadav [this message]
2015-11-25 1:38 ` John Wiegley
2015-11-25 1:46 ` Maneesh Yadav
2015-11-25 1:50 ` John Wiegley
2015-11-25 18:49 ` Maneesh Yadav
2015-11-25 18:59 ` John Wiegley
2016-02-18 21:46 ` Maneesh Yadav
2016-02-20 2:40 ` John Wiegley
2020-08-31 2:11 ` Stefan Kangas
2020-08-31 2:25 ` Maneesh Yadav
2020-08-31 13:54 ` Stefan Kangas
2015-11-20 22:01 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPsivR8bVdaEdHoRvk05HOmm=SLZwPFM7ZjZcvwNwPkCAq9i5w@mail.gmail.com' \
--to=maneeshkyadav@gmail.com \
--cc=21965@debbugs.gnu.org \
--cc=jwiegley@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.