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: Wed, 25 Nov 2015 10:49:29 -0800 [thread overview]
Message-ID: <CAPsivR88n8W-f4y8zWsmaQnrYPGHGNx8t=qcvTcrqYc6mVm_6Q@mail.gmail.com> (raw)
In-Reply-To: <m2a8q2hmob.fsf@newartisans.com>
Weird.
I patched glib2 this way (just overriding the macros (and removing
semicolons on macro invocations...seemed to be the best way to deal
with if statements that didn't wrap in curly braces...just realized my
strings don't reflect "UN"LOCK/LOCK....not a big deal since line
numbers are there...fixed for next time):
#define LOCK_CONTEXT(context) g_mutex_lock (&context->mutex)
#define LOCK_CONTEXT(context) {printf("MANEESH GLIB DEBUG: About to
LOCK: %s, %d, %s\n", __FILE__, __LINE__, __FUNCTION__); g_mutex_lock
(&context->mutex);}
#define UNLOCK_CONTEXT(context) g_mutex_unlock (&context->mutex)
#define UNLOCK_CONTEXT(context) {printf("MANEESH GLIB DEBUG: About to
LOCK: %s, %d, %s\n", __FILE__, __LINE__, __FUNCTION__); g_mutex_unlock
(&context->mutex);}
Grabbing the output (emacs -Q > test.out) shows the stall mid print:
MANEESH GLIB DEBUG: About to LOCK: gmain.c, 3208, g_main_context_acquire
MANEESH GLIB DEBUG: About to LOCK: gmain.c, 3222, g_main_context_acquire
MANEESH GLIB DEBUG: About to LOCK: gmain.c, 3801, g_main_context_iterate
MANEESH GLIB DEBUG: About to LOCK: gmain.c, 3812, g_main_context_iterate
MANEESH GLIB DEBUG: About to LOCK: gmain.c, 3376, g_main_context_prepare
MANEESH GLIB DEBUG: About to LOCK: gmain.c, 3501, g_main_context_prepare
MANEESH GLIB DEBUG
gmain.c 3501 region:
if (timeout)
{
*timeout = context->timeout;
if (*timeout != 0)
context->time_is_fresh = FALSE;
}
UNLOCK_CONTEXT (context)
return n_poll;
Nothing terribly different from the lldb backtrace (for completeness):
(lldb) thread backtrace all
* thread #1: tid = 0x9bb3c, 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: 0x0000000100a17b78 libglib-2.0.0.dylib`g_mutex_lock + 26
frame #3: 0x00000001009da551 libglib-2.0.0.dylib`g_main_context_acquire + 78
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 = 0x9bb48, 0x00007fff8a8613fa
libsystem_kernel.dylib`__select + 10, name = 'gmain'
frame #0: 0x00007fff8a8613fa libsystem_kernel.dylib`__select + 10
frame #1: 0x00000001009e8bed libglib-2.0.0.dylib`g_poll + 399
frame #2: 0x00000001009dd303
libglib-2.0.0.dylib`g_main_context_iterate + 627
frame #3: 0x00000001009dd40e
libglib-2.0.0.dylib`g_main_context_iteration + 104
frame #4: 0x00000001009de7c6 libglib-2.0.0.dylib`glib_worker_main + 53
frame #5: 0x00000001009fde09 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
Everything is terrible.
On Tue, Nov 24, 2015 at 5:50 PM, John Wiegley <jwiegley@gmail.com> wrote:
>>>>>> Maneesh Yadav <maneeshkyadav@gmail.com> writes:
>
>>> To go deeper, we may need to build a separate copy of glib and start
>>> putting some print statements in to find out why there is lock contention.
>>> Would you be up for that? I'd like to know if this is happening in
>>> g_get_worker_context.
>
> I've read further, and since "static gsize initialised;" must initialize to
> zero, it's for me to see how this code could be wrong just from reading it.
>
> I'd like to find every line of code in glib that calls LOCK_CONTEXT or
> UNLOCK_CONTEXT, and print out:
>
> Function, file, line, lock or unlock, pointer value of context
>
> That should help us narrow it down.
>
> John
next prev parent reply other threads:[~2015-11-25 18:49 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
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 [this message]
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='CAPsivR88n8W-f4y8zWsmaQnrYPGHGNx8t=qcvTcrqYc6mVm_6Q@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.