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

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

[Maneesh Yadav]

I was experiencing frequent 'freezing' after pressing 'Ctrl-g-g' (I
think I have defaulted to pressing twice to make sure I've cancelled out
of partial command, seeing "quit" makes me feel happier than "C-x C-g is
undefined").

This doesn't seem completely repeatable (but I did just do it on my
first try just now): I start 'emacs -Q' and Ctrl-x Ctrl-f to see a
prompt in the minibuffer for a file and then Ctrl-g Ctrl-g then emacs
freezes (does not respond to Ctrl-g or any keystrokes...I don't think
I'm naively invoking an process control key binding (checked with stty-a).




Ugh, I am behind on my debug skills, I couldn't find out how to
compile my macports version with debug symbols.  After I kill  with
"pkill -USR2 emacs", I get this output (is this useful?):

0   emacs                               0x000000010009ebe9
emacs_backtrace + 87
1   emacs                               0x0000000100084ffa
terminate_due_to_signal + 97
2   emacs                               0x000000010009d77b
init_baud_rate + 0
3   emacs                               0x000000010008e5d3
handle_interrupt + 590
4   emacs                               0x000000010009e808
deliver_process_signal + 53
5   libsystem_platform.dylib            0x00007fff8c44df1a _sigtramp +
26
6   ???                                 0x0646666406466664 0x0 +
452161392385353316
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
14  emacs                               0x0000000100088973
command_loop_1 + 3983
15  emacs                               0x00000001000f251e
internal_condition_case + 251
16  emacs                               0x00000001000966c9
command_loop_2 + 53
17  emacs                               0x00000001000f1f48
internal_catch + 243
18  emacs                               0x00000001000871ea
recursive_edit_1 + 206
19  emacs                               0x000000010008738d
Frecursive_edit + 236
20  emacs                               0x000000010008648e main + 4658
21  libdyld.dylib                       0x00007fff8707a5c9 start + 1
22  ???                                 0x0000000000000001 0x0 + 1



In GNU Emacs 24.5.1 (x86_64-apple-darwin14.4.0)
 of 2015-08-25 on Maneeshs-MacBook-Air.local
Configured using:
 `configure --prefix=/opt/local --without-x --without-dbus
 --without-gconf --without-libotf --without-m17n-flt --without-gpm
 --without-gnutls --with-xml2 --infodir /opt/local/share/info/emacs
 'CFLAGS=-pipe -Os -arch x86_64' CPPFLAGS=-I/opt/local/include
 'LDFLAGS=-L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-no_pie
 -arch x86_64''

Important settings:
  value of $LC_ALL: en_US.UTF-8
  value of $LC_CTYPE: en_US.UTF-8
  value of $LANG: us
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list... [2 times]

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail regexp-opt rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils help-mode easymenu xterm
time-date tooltip electric uniquify ediff-hook vc-hooks lisp-float-type
tabulated-list newcomment lisp-mode prog-mode register page menu-bar
rfn-eshadow timer select mouse jit-lock font-lock syntax facemenu
font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer nadvice loaddefs button
faces cus-face macroexp files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process gfilenotify multi-tty emacs)

Memory information:
((conses 16 74606 6954)
 (symbols 48 16694 0)
 (miscs 40 32 141)
 (strings 32 9404 4608)
 (string-bytes 1 257827)
 (vectors 16 7133)
 (vector-slots 8 335922 32343)
 (floats 8 52 663)
 (intervals 56 176 13)
 (buffers 960 12))

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

[John Wiegley]

>>>>> Maneesh Yadav <maneeshkyadav@gmail.com> writes:

> I was experiencing frequent 'freezing' after pressing 'Ctrl-g-g' (I think I
> have defaulted to pressing twice to make sure I've cancelled out of partial
> command, seeing "quit" makes me feel happier than "C-x C-g is undefined").

Only twice? I think my default right now is 10-20 times, just for that extra
satisfying feel.

> This doesn't seem completely repeatable (but I did just do it on my first
> try just now): I start 'emacs -Q' and Ctrl-x Ctrl-f to see a prompt in the
> minibuffer for a file and then Ctrl-g Ctrl-g then emacs freezes (does not
> respond to Ctrl-g or any keystrokes...I don't think I'm naively invoking an
> process control key binding (checked with stty-a).

I've experienced deadlocks in the past as well, although recently there have
been none. What else are you doing when this happens? Are you using tramp,
running any background processes, etc.?

John

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

[Maneesh Yadav]

Hi John,
I'm running in a mac environment with nothing really going on in the
background (a web browser, mail, another shell or two open with
prompt).  No tramp or fancy filesystem stuff or anything (even without
-Q I think my startup is fairly modest).  I should correct my
replication path, I believe I am pressing Ctrl-g-g...but I've
replicated the bug with mashing Ctrl-gs when the minibuffer is waiting
for input, not clear that the minibuffer is the only context this
happens.

Thanks so much for your fast response, I hope this is real bug.  I
held off on reporting it for awhile since I wanted to be sure it
wasn't something idiotic I am doing.

> This doesn't seem completely repeatable (but I did just do it on my first
> try just now): I start 'emacs -Q' and Ctrl-x Ctrl-f to see a prompt in the
> minibuffer for a file and then Ctrl-g-g then emacs freezes (does not
> respond to Ctrl-g or any keystrokes...I don't think I'm naively invoking an
> process control key binding (checked with stty-a).

On Fri, Nov 20, 2015 at 1:37 PM, John Wiegley <jwiegley@gmail.com> wrote:
>>>>>> Maneesh Yadav <maneeshkyadav@gmail.com> writes:
>
>> I was experiencing frequent 'freezing' after pressing 'Ctrl-g-g' (I think I
>> have defaulted to pressing twice to make sure I've cancelled out of partial
>> command, seeing "quit" makes me feel happier than "C-x C-g is undefined").
>
> Only twice? I think my default right now is 10-20 times, just for that extra
> satisfying feel.
>
>> This doesn't seem completely repeatable (but I did just do it on my first
>> try just now): I start 'emacs -Q' and Ctrl-x Ctrl-f to see a prompt in the
>> minibuffer for a file and then Ctrl-g Ctrl-g then emacs freezes (does not
>> respond to Ctrl-g or any keystrokes...I don't think I'm naively invoking an
>> process control key binding (checked with stty-a).
>
> I've experienced deadlocks in the past as well, although recently there have
> been none. What else are you doing when this happens? Are you using tramp,
> running any background processes, etc.?
>
> John

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

[John Wiegley]

>>>>> Maneesh Yadav <maneeshkyadav@gmail.com> writes:

> Thanks so much for your fast response, I hope this is real bug. I held off
> on reporting it for awhile since I wanted to be sure it wasn't something
> idiotic I am doing.

I'm pretty sure it's a real bug, since I've encountered it before too. I was
forced to "kill -9 PID" to restart Emacs. It used to happen to me at least
once a day, and always after having left Emacs idle for a while.

I wonder, does it also happen if you try the 'Mac port' version of Carbon
Emacs, by Yamamoto Matsuhiro? See:

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/

I think that may have been how I resolved it here, and I haven't switched back
to Cocoa yet.

John

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

[Eli Zaretskii]

> Date: Fri, 20 Nov 2015 11:18:41 -0800
> From: Maneesh Yadav <maneeshkyadav@gmail.com>
> 
> This doesn't seem completely repeatable (but I did just do it on my
> first try just now): I start 'emacs -Q' and Ctrl-x Ctrl-f to see a
> prompt in the minibuffer for a file and then Ctrl-g Ctrl-g then emacs
> freezes (does not respond to Ctrl-g or any keystrokes...I don't think
> I'm naively invoking an process control key binding (checked with stty-a).

Not reproducible here (but I'm not on Darwin).

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

[Maneesh Yadav]

Indeed, I run into it frequently enough it causes pain.

When I replicated the bug for this report, I did it right after emacs
started (and I was in scratch buffer) FWIW; so idling (in this case)
wasn't necessary.  I'll try one of the other mac emacs versions.


I've tried it a few times just now and haven't been able to make it
occur again (though it happens on its own often enough that I know
I'll see it again soon).

On Fri, Nov 20, 2015 at 1:55 PM, John Wiegley <jwiegley@gmail.com> wrote:
>>>>>> Maneesh Yadav <maneeshkyadav@gmail.com> writes:
>
>> Thanks so much for your fast response, I hope this is real bug. I held off
>> on reporting it for awhile since I wanted to be sure it wasn't something
>> idiotic I am doing.
>
> I'm pretty sure it's a real bug, since I've encountered it before too. I was
> forced to "kill -9 PID" to restart Emacs. It used to happen to me at least
> once a day, and always after having left Emacs idle for a while.
>
> I wonder, does it also happen if you try the 'Mac port' version of Carbon
> Emacs, by Yamamoto Matsuhiro? See:
>
>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/
>
> I think that may have been how I resolved it here, and I haven't switched back
> to Cocoa yet.
>
> John

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

[Maneesh Yadav]

Ok I just did it again had to mash Ctrl-g a little (still not sure if
it is Ctrl-g-g or Ctrl-g Ctrl-g that triggers it) but a similar
backtrace.  Just confirming I could replicate it 'on command' (sort
of).

emacs -Q

Auto-save? (y or n) n

Abort (and dump core)? (y or n) y

Fatal error 6: Abort trap

Backtrace:

0   emacs                               0x000000010009ebe9 emacs_backtrace + 87

1   emacs                               0x0000000100084ffa
terminate_due_to_signal + 97

2   emacs                               0x000000010009d77b init_baud_rate + 0

3   emacs                               0x000000010008e5d3
handle_interrupt + 590

4   emacs                               0x000000010009e808
deliver_process_signal + 53

5   libsystem_platform.dylib            0x00007fff8c44df1a _sigtramp + 26

6   ???                                 0x0000000000000000 0x0 + 0

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

14  emacs                               0x0000000100088973 command_loop_1 + 3983

15  emacs                               0x00000001000f251e
internal_condition_case + 251

16  emacs                               0x00000001000966c9 command_loop_2 + 53

17  emacs                               0x00000001000f1f48 internal_catch + 243

18  emacs                               0x00000001000871ea
recursive_edit_1 + 206

19  emacs                               0x000000010008738d Frecursive_edit + 236

20  emacs                               0x000000010008648e main + 4658

21  libdyld.dylib                       0x00007fff8707a5c9 start + 1

On Fri, Nov 20, 2015 at 2:07 PM, Maneesh Yadav <maneeshkyadav@gmail.com> wrote:
> Indeed, I run into it frequently enough it causes pain.
>
> When I replicated the bug for this report, I did it right after emacs
> started (and I was in scratch buffer) FWIW; so idling (in this case)
> wasn't necessary.  I'll try one of the other mac emacs versions.
>
>
> I've tried it a few times just now and haven't been able to make it
> occur again (though it happens on its own often enough that I know
> I'll see it again soon).
>
> On Fri, Nov 20, 2015 at 1:55 PM, John Wiegley <jwiegley@gmail.com> wrote:
>>>>>>> Maneesh Yadav <maneeshkyadav@gmail.com> writes:
>>
>>> Thanks so much for your fast response, I hope this is real bug. I held off
>>> on reporting it for awhile since I wanted to be sure it wasn't something
>>> idiotic I am doing.
>>
>> I'm pretty sure it's a real bug, since I've encountered it before too. I was
>> forced to "kill -9 PID" to restart Emacs. It used to happen to me at least
>> once a day, and always after having left Emacs idle for a while.
>>
>> I wonder, does it also happen if you try the 'Mac port' version of Carbon
>> Emacs, by Yamamoto Matsuhiro? See:
>>
>>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/
>>
>> I think that may have been how I resolved it here, and I haven't switched back
>> to Cocoa yet.
>>
>> John

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

[John Wiegley]

>>>>> Maneesh Yadav <maneeshkyadav@gmail.com> writes:

> Ok I just did it again had to mash Ctrl-g a little (still not sure if it is
> Ctrl-g-g or Ctrl-g Ctrl-g that triggers it) but a similar backtrace. Just
> confirming I could replicate it 'on command' (sort of).

Ok, the next step will be to build you Emacs with debugging, and see if that
adds more to the trace. We may need to start adding some print statements, to
find out if `wait_reading_process_output' is really the blocking call.

John

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

[Maneesh Yadav]

Apologies for the debug newbieness...this shows that the debug symbols
are in there, correct?

maneeshyadav$ otool -Iv /opt/local/bin/emacs

/opt/local/bin/emacs:

Indirect symbols for (__TEXT,__stubs) 256 entries

address            index name

0x0000000100151d60  6480 _htmlReadMemory

0x0000000100151d66  6610 _xmlCheckVersion

0x0000000100151d6c  6611 _xmlCleanupParser

0x0000000100151d72  6612 _xmlDocGetRootElement

0x0000000100151d78  6613 _xmlFreeDoc

0x0000000100151d7e  6614 _xmlReadMemory

0x0000000100151d84  6588 _tgetent

0x0000000100151d8a  6589 _tgetflag

0x0000000100151d90  6590 _tgetnum

0x0000000100151d96  6591 _tgetstr

0x0000000100151d9c  6592 _tgoto

0x0000000100151da2  6596 _tparm

0x0000000100151da8  6597 _tputs

0x0000000100151dae  6352 __NSGetEnviron

0x0000000100151db4  6353 ___assert_rtn

On Fri, Nov 20, 2015 at 3:26 PM, John Wiegley <jwiegley@gmail.com> wrote:
>>>>>> Maneesh Yadav <maneeshkyadav@gmail.com> writes:
>
>> Ok I just did it again had to mash Ctrl-g a little (still not sure if it is
>> Ctrl-g-g or Ctrl-g Ctrl-g that triggers it) but a similar backtrace. Just
>> confirming I could replicate it 'on command' (sort of).
>
> Ok, the next step will be to build you Emacs with debugging, and see if that
> adds more to the trace. We may need to start adding some print statements, to
> find out if `wait_reading_process_output' is really the blocking call.
>
> John

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

[John Wiegley]

>>>>> Maneesh Yadav <maneeshkyadav@gmail.com> writes:

> Apologies for the debug newbieness...this shows that the debug symbols are
> in there, correct?

Only the symbol table is there (i.e., it hasn't been stripped), not the debug
info (i.e., -g) that correlates TEXT addresses with file and line numbers.

John

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

[Maneesh Yadav]

Ugh, this is not a part of emacs, but for the sake of anyone else who
has to to do the same in the future.  Does anyone have hints as to
building the debug version of macport emacs?

I did:
port dir emacs
(backed up original portfile)
added compiler flags -O0 and -g

*not quite sure where how to to run dsym...

Assuming I can edit the portfile properly then I should be able to
building the debug emacs binary.  If anyone already has a clever way
of doing this, please let me know otherwise I will trudge through
macports.

On Fri, Nov 20, 2015 at 3:54 PM, John Wiegley <jwiegley@gmail.com> wrote:
>>>>>> Maneesh Yadav <maneeshkyadav@gmail.com> writes:
>
>> Apologies for the debug newbieness...this shows that the debug symbols are
>> in there, correct?
>
> Only the symbol table is there (i.e., it hasn't been stripped), not the debug
> info (i.e., -g) that correlates TEXT addresses with file and line numbers.
>
> John

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

[Eli Zaretskii]

> Date: Fri, 20 Nov 2015 14:45:23 -0800
> From: Maneesh Yadav <maneeshkyadav@gmail.com>
> Cc: 21965@debbugs.gnu.org
> 
> Ok I just did it again had to mash Ctrl-g a little (still not sure if
> it is Ctrl-g-g or Ctrl-g Ctrl-g that triggers it) but a similar
> backtrace.  Just confirming I could replicate it 'on command' (sort
> of).
> 
> emacs -Q
> Auto-save? (y or n) n
> Abort (and dump core)? (y or n) y
> Fatal error 6: Abort trap
> 
> Backtrace:
> 0   emacs                               0x000000010009ebe9 emacs_backtrace + 87
> 1   emacs                               0x0000000100084ffa
> terminate_due_to_signal + 97
> 2   emacs                               0x000000010009d77b init_baud_rate + 0
> 3   emacs                               0x000000010008e5d3
> handle_interrupt + 590
> 4   emacs                               0x000000010009e808
> deliver_process_signal + 53
> 5   libsystem_platform.dylib            0x00007fff8c44df1a _sigtramp + 26
> 6   ???                                 0x0000000000000000 0x0 + 0
> 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.

We need to know where it hangs or infloops prior to that.

Thanks.

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

[John Wiegley]

>>>>> 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

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

[Maneesh Yadav]

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

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

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

[John Wiegley]

>>>>> Maneesh Yadav <maneeshkyadav@gmail.com> writes:

> 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?):

We're still missing file and line numbers for the Emacs code, which is odd.
But not terribly important, since the lockup is happening inside glib, it
appears.

>     frame #3: 0x00000001009db284
>     libglib-2.0.0.dylib`g_main_context_acquire + 42

So, here's that function, more or less:

    gboolean 
    g_main_context_acquire (GMainContext *context)
    {
      gboolean result = FALSE;
      GThread *self = G_THREAD_SELF;
    
      if (context == NULL)
        context = g_main_context_default ();
      
      LOCK_CONTEXT (context);
      /* ... */
    }

We're blocked waiting on the context. The question then being: who else has
that context? Is it another Emacs thread?

Eli, does this ring any bells?

John

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

[Maneesh Yadav]

I don't understand the apple framework/glib event handling structure
and I doubt this is terribly informative, but for the sake of
completeness the output of 'thread list' is pasted below:

(lldb) thread list

Process 23166 stopped

* thread #1: tid = 0x4d18b, 0x00007fff8a861166
libsystem_kernel.dylib`__psynch_mutexwait + 10, queue =
'com.apple.main-thread', stop reason = signal SIGSTOP

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

(lldb)


On Mon, Nov 23, 2015 at 2:17 PM, John Wiegley <jwiegley@gmail.com> wrote:
>>>>>> Maneesh Yadav <maneeshkyadav@gmail.com> writes:
>
>> 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?):
>
> We're still missing file and line numbers for the Emacs code, which is odd.
> But not terribly important, since the lockup is happening inside glib, it
> appears.
>
>>     frame #3: 0x00000001009db284
>>     libglib-2.0.0.dylib`g_main_context_acquire + 42
>
> So, here's that function, more or less:
>
>     gboolean
>     g_main_context_acquire (GMainContext *context)
>     {
>       gboolean result = FALSE;
>       GThread *self = G_THREAD_SELF;
>
>       if (context == NULL)
>         context = g_main_context_default ();
>
>       LOCK_CONTEXT (context);
>       /* ... */
>     }
>
> We're blocked waiting on the context. The question then being: who else has
> that context? Is it another Emacs thread?
>
> Eli, does this ring any bells?
>
> John

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

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  21965@debbugs.gnu.org
> Date: Mon, 23 Nov 2015 14:17:17 -0800
> 
> We're still missing file and line numbers for the Emacs code, which is odd.
> But not terribly important, since the lockup is happening inside glib, it
> appears.
> 
> >     frame #3: 0x00000001009db284
> >     libglib-2.0.0.dylib`g_main_context_acquire + 42
> 
> So, here's that function, more or less:
> 
>     gboolean 
>     g_main_context_acquire (GMainContext *context)
>     {
>       gboolean result = FALSE;
>       GThread *self = G_THREAD_SELF;
>     
>       if (context == NULL)
>         context = g_main_context_default ();
>       
>       LOCK_CONTEXT (context);
>       /* ... */
>     }
> 
> We're blocked waiting on the context. The question then being: who else has
> that context? Is it another Emacs thread?
> 
> Eli, does this ring any bells?

No.  And I'm not even convinced that's where we are blocked.  It could
be that this is part of a loop that Emacs is waiting in.  To prove
that we are blocked there, one needs to attach the debugger many times
and see that the debugger finds Emacs at _exactly_ the same
instruction.  Or, after attaching, step Emacs and see that it cannot
move even a single instructions.

If this is really what happens, and Emacs cannot acquire a mutex, that
would mean someone is holding that mutex, and the question is who that
someone is.

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

[Eli Zaretskii]

> Date: Mon, 23 Nov 2015 16:30:59 -0800
> From: Maneesh Yadav <maneeshkyadav@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, 21965@debbugs.gnu.org
> 
> I don't understand the apple framework/glib event handling structure
> and I doubt this is terribly informative, but for the sake of
> completeness the output of 'thread list' is pasted below:
> 
> (lldb) thread list
> 
> Process 23166 stopped
> 
> * thread #1: tid = 0x4d18b, 0x00007fff8a861166
> libsystem_kernel.dylib`__psynch_mutexwait + 10, queue =
> 'com.apple.main-thread', stop reason = signal SIGSTOP
> 
>   thread #2: tid = 0x4d18c, 0x00007fff8a8613fa
> libsystem_kernel.dylib`__select + 10, name = 'gmain'
> 
> (lldb)

Where did that STOP signal come from?  Could that be the debugger
itself?

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

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> No. And I'm not even convinced that's where we are blocked. It could be that
> this is part of a loop that Emacs is waiting in. To prove that we are
> blocked there, one needs to attach the debugger many times and see that the
> debugger finds Emacs at _exactly_ the same instruction. Or, after attaching,
> step Emacs and see that it cannot move even a single instructions.

Fair enough.  The docs for g_main_context_acquire do say that it should return
immediately, if no other thread is holding the lock.

John

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

[Maneesh Yadav]

FWIW I just triggered the condition 3 times in a row (I seem to be
getting better at triggering it), attached with lldb output
(backtraces looks the same as before as well).  Looks like the same
instruction?


#1



Process 25176 stopped

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


(lldb) thread backtrace

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



#2

Process 25238 stopped

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



#3

Process 25251 stopped

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


On Mon, Nov 23, 2015 at 7:39 PM, John Wiegley <jwiegley@gmail.com> wrote:
>>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>
>> No. And I'm not even convinced that's where we are blocked. It could be that
>> this is part of a loop that Emacs is waiting in. To prove that we are
>> blocked there, one needs to attach the debugger many times and see that the
>> debugger finds Emacs at _exactly_ the same instruction. Or, after attaching,
>> step Emacs and see that it cannot move even a single instructions.
>
> Fair enough.  The docs for g_main_context_acquire do say that it should return
> immediately, if no other thread is holding the lock.
>
> John

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

[Maneesh Yadav]

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.


(lldb) thread step-in

Process 25251 stopped

* thread #1: tid = 0x746f0, 0x00007fff8a861168
libsystem_kernel.dylib`__psynch_mutexwait + 12, queue =
'com.apple.main-thread', stop reason = instruction step into

    frame #0: 0x00007fff8a861168 libsystem_kernel.dylib`__psynch_mutexwait + 12

libsystem_kernel.dylib`__psynch_mutexwait:

->  0x7fff8a861168 <+12>: movq   %rax, %rdi

    0x7fff8a86116b <+15>: jmp    0x7fff8a85cc53            ; cerror_nocancel

    0x7fff8a861170 <+20>: retq

    0x7fff8a861171 <+21>: nop

(lldb) thread step-in

Process 25251 stopped

* thread #1: tid = 0x746f0, 0x00007fff8a86116b
libsystem_kernel.dylib`__psynch_mutexwait + 15, queue =
'com.apple.main-thread', stop reason = instruction step into

    frame #0: 0x00007fff8a86116b libsystem_kernel.dylib`__psynch_mutexwait + 15

libsystem_kernel.dylib`__psynch_mutexwait:

->  0x7fff8a86116b <+15>: jmp    0x7fff8a85cc53            ; cerror_nocancel

    0x7fff8a861170 <+20>: retq

    0x7fff8a861171 <+21>: nop

    0x7fff8a861172 <+22>: nop

(lldb) thread step-in

Process 25251 stopped

* thread #1: tid = 0x746f0, 0x00007fff8a85cc53
libsystem_kernel.dylib`cerror_nocancel, queue =
'com.apple.main-thread', stop reason = instruction step into

    frame #0: 0x00007fff8a85cc53 libsystem_kernel.dylib`cerror_nocancel

libsystem_kernel.dylib`cerror_nocancel:

->  0x7fff8a85cc53 <+0>:  movl   %edi, -0x14ad19d9(%rip)   ; errno

    0x7fff8a85cc59 <+6>:  movq   %gs:0x8, %rax

    0x7fff8a85cc62 <+15>: testq  %rax, %rax

    0x7fff8a85cc65 <+18>: je     0x7fff8a85cc69            ; <+22>

On Tue, Nov 24, 2015 at 2:51 PM, Maneesh Yadav <maneeshkyadav@gmail.com> wrote:
> FWIW I just triggered the condition 3 times in a row (I seem to be
> getting better at triggering it), attached with lldb output
> (backtraces looks the same as before as well).  Looks like the same
> instruction?
>
>
> #1
>
>
>
> Process 25176 stopped
>
> * thread #1: tid = 0x7369a, 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
>
>
> (lldb) thread backtrace
>
> * thread #1: tid = 0x7369a, 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
> ...
>
>
>
> #2
>
> Process 25238 stopped
>
> * thread #1: tid = 0x742be, 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
>
>
>
> #3
>
> Process 25251 stopped
>
> * thread #1: tid = 0x746f0, 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
>
>
> On Mon, Nov 23, 2015 at 7:39 PM, John Wiegley <jwiegley@gmail.com> wrote:
>>>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>> No. And I'm not even convinced that's where we are blocked. It could be that
>>> this is part of a loop that Emacs is waiting in. To prove that we are
>>> blocked there, one needs to attach the debugger many times and see that the
>>> debugger finds Emacs at _exactly_ the same instruction. Or, after attaching,
>>> step Emacs and see that it cannot move even a single instructions.
>>
>> Fair enough.  The docs for g_main_context_acquire do say that it should return
>> immediately, if no other thread is holding the lock.
>>
>> John

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

[John Wiegley]

>>>>> 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

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

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

[John Wiegley]

>>>>> Maneesh Yadav <maneeshkyadav@gmail.com> writes:

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

Ok! Now we know what the deadlock situation is:

Thread #2:

>     frame #3: 0x00000001009dd716 libglib-2.0.0.dylib`g_main_context_iteration + 55
...
>     frame #0: 0x00007fff8a8613fa libsystem_kernel.dylib`__select + 10

Thread #1:

>     frame #3: 0x00000001009db284 libglib-2.0.0.dylib`g_main_context_acquire + 42

It turns out that both g_main_context_acquire and g_main_context_iteration
(when called with NULL) call LOCK_CONTEXT on the "default context".

Now, I *think* the context should be different between these two threads: one
should be the default context, and one should be the worker context. But it
_looks_ like Thread #1 is being locked out by Thread #2.

In fact, reading the glib code, if the call to g_once_init_enter returns FALSE
within g_get_worker_context, then the worker context will be NULL! Which seems
like a subtle bug waiting to happen, and might be what's biting us.

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.

John

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

[Maneesh Yadav]

For sure...let me make sure I can insert print statements into glib in
the context of my macports install (and get a little better
understanding of the glib event loop). Will write back once that is
up.


On Tue, Nov 24, 2015 at 5:38 PM, John Wiegley <jwiegley@gmail.com> wrote:
>>>>>> Maneesh Yadav <maneeshkyadav@gmail.com> writes:
>
>> I still am uncomfortable with my comprehension of the lldb output but here
>> is 'backtrace all' after triggering the condition
>
> Ok! Now we know what the deadlock situation is:
>
> Thread #2:
>
>>     frame #3: 0x00000001009dd716 libglib-2.0.0.dylib`g_main_context_iteration + 55
> ...
>>     frame #0: 0x00007fff8a8613fa libsystem_kernel.dylib`__select + 10
>
> Thread #1:
>
>>     frame #3: 0x00000001009db284 libglib-2.0.0.dylib`g_main_context_acquire + 42
>
> It turns out that both g_main_context_acquire and g_main_context_iteration
> (when called with NULL) call LOCK_CONTEXT on the "default context".
>
> Now, I *think* the context should be different between these two threads: one
> should be the default context, and one should be the worker context. But it
> _looks_ like Thread #1 is being locked out by Thread #2.
>
> In fact, reading the glib code, if the call to g_once_init_enter returns FALSE
> within g_get_worker_context, then the worker context will be NULL! Which seems
> like a subtle bug waiting to happen, and might be what's biting us.
>
> 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.
>
> John

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

[John Wiegley]

>>>>> 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

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

[Maneesh Yadav]

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

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

[John Wiegley]

>>>>> Maneesh Yadav <maneeshkyadav@gmail.com> writes:

> 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):

Nice, this is much closer. I just need you to add a %p formatting string, and
then print the value of the "context":

 #define LOCK_CONTEXT(context) {printf("MANEESH GLIB DEBUG: About to LOCK %p:
 %s, %d, %\n", context, __FILE__, __LINE__, __FUNCTION__); g_mutex_lock
 (&context->mutex);}

John

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

[Maneesh Yadav]

Apologies to all I haven't ben able to follow up on this more
thoroughly, part of the problem was trying to get the crash to
replicate.  I could do it in a few minutes while I was originally
posting, then as I was getting all the right debug statements in it
got harder and harder.  I decided to just revert to normal use and
wait for it to happen.  Just happened again and I've put all the
debugging info I can here and will try to trace through glib and
figure out what is going on, just putting everything here for
reference.

overrided the following macros in gmain.c (and had to add some curly braces):

#define LOCK_CONTEXT(context) g_mutex_lock (&context->mutex)
#define LOCK_CONTEXT(context) {fprintf(stderr, "MANEESH GLIB DEBUG:
About to LOCK: %p, %s, %d, %s, %p\n", context, __FILE__, __LINE__,
__FUNCTION__,g_thread_self()); g_mutex_lock (&context->mutex);}

#define UNLOCK_CONTEXT(context) g_mutex_unlock (&context->mutex)
#define UNLOCK_CONTEXT(context) {fprintf(stderr, "MANEESH GLIB DEBUG:
About to UNLOCK: %p, %s, %d, %s, %p\n", context, __FILE__, __LINE__,
__FUNCTION__, g_thread_self()); g_mutex_unlock (&context->mutex);}


At the time of crash, an abbreviated summary of stderr:
...
MANEESH GLIB DEBUG: About to UNLOCK: 0x100f00e20, gmain.c, 4128,
g_main_context_poll, 0x102001c00

MANEESH GLIB DEBUG: About to LOCK: 0x100d8a3a0, gmain.c, 3208,
g_main_context_acquire, 0x100da5800

MANEESH GLIB DEBUG: About to UNLOCK: 0x100d8a3a0, gmain.c, 3222,
g_main_context_acquire, 0x100da5800

MANEESH GLIB DEBUG: About to LOCK: 0x100d8a3a0, gmain.c, 3538,
g_main_context_query, 0x100da5800

MANEESH GLIB DEBUG: About to UNLOCK: 0x100d8a3a0, gmain.c, 3583,
g_main_context_query, 0x100da5800

MANEESH GLIB DEBUG: About to LOCK: 0x100d8a3a0, gmain.c, 3859,
g_main_context_pending, 0x100da5800

MANEESH GLIB DEBUG: About to UNLOCK: 0x100d8a3a0, gmain.c, 3782,
g_main_context_iterate, 0x100da5800

MANEESH GLIB DEBUG: About to LOCK: 0x100d8a3a0, gmain.c, 3208,
g_main_context_acquire, 0x100da5800

MANEESH GLIB DEBUG: About to UNLOCK: 0x100d8a3a0, gmain.c, 3222,
g_main_context_acquire, 0x100da5800

MANEESH GLIB DEBUG: About to LOCK: 0x100d8a3a0, gmain.c, 3801,
g_main_context_iterate, 0x100da5800

MANEESH GLIB DEBUG: About to UNLOCK: 0x100d8a3a0, gmain.c, 3812,
g_main_context_iterate, 0x100da5800

MANEESH GLIB DEBUG: About to LOCK: 0x100d8a3a0, gmain.c, 3376,
g_main_context_prepare, 0x100da5800

MANEESH GLIB DEBUG: About to UNLOCK: 0x100d8a3a0, gmain.c, 3501,
g_main_context_prepare, 0x100da5800

MANEESH GLIB DEBUG: About to LOCK: 0x100d8a3a0, gmain.c, 3538,
g_main_context_query, 0x100da5800

MANEESH GLIB DEBUG: About to UNLOCK: 0x100d8a3a0, gmain.c, 3583,
g_main_context_query, 0x100da5800

MANEESH GLIB DEBUG: About to LOCK: 0x100d8a3a0, gmain.c, 4124,
g_main_context_poll, 0x100da5800

MANEESH GLIB DEBUG: About to UNLOCK: 0x100d8a3a0, gmain.c, 4128,
g_main_context_poll, 0x100da5800

...

MANEESH GLIB DEBUG: About to LOCK: 0x100d8a3a0, gmain.c, 3242,
g_main_context_release, 0x100da5800

MANEESH GLIB DEBUG: About to UNLOCK: 0x100d8a3a0, gmain.c, 3265,
g_main_context_release, 0x100da5800

MANEESH GLIB DEBUG: About to LOCK: 0x100d8a3a0, gmain.c, 3208,
g_main_context_acquire, 0x100da5800

MANEESH GLIB DEBUG: About to LOCK: 0x100d8a3a0, gmain.c, 3208,
g_main_context_acquire, 0x100da5800

MANEESH GLIB DEBUG: About to LOCK: 0x100d8a3a0, gmain.c, 3208,
g_main_context_acquire, 0x100da5800

MANEESH GLIB DEBUG: About to LOCK: 0x100d8a3a0, gmain.c, 3208,
g_main_context_acquire, 0x100da5800

MANEESH GLIB DEBUG: About to LOCK: 0x100d8a3a0, gmain.c, 3208,
g_main_context_acquire, 0x100da5800

MANEESH GLIB DEBUG: About to LOCK: 0x100d8a3a0, gmain.c, 3208,
g_main_context_acquire, 0x100da5800

MANEESH GLIB DEBUG: About to LOCK: 0x100d8a3a0, gmain.c, 3208,
g_main_context_acquire, 0x100da5800

MANEESH GLIB DEBUG: About to LOCK: 0x100d8a3a0, gmain.c, 3208,
g_main_context_acquire, 0x100da5800

MANEESH GLIB DEBUG: About to LOCK: 0x100d8a3a0, gmain.c, 3208,
g_main_context_acquire, 0x100da5800

MANEESH GLIB DEBUG: About to LOCK: 0x100d8a3a0, gmain.c, 3208,
g_main_context_acquire, 0x100da5800

MANEESH GLIB DEBUG: About to LOCK: 0x100d8a3a0, gmain.c, 3208,
g_main_context_acquire, 0x100da5800

MANEESH GLIB DEBUG: About to LOCK: 0x100d8a3a0, gmain.c, 3208,
g_main_context_acquire, 0x100da5800

MANEESH GLIB DEBUG: About to LOCK: 0x100d8a3a0, gmain.c, 3208,
g_main_context_acquire, 0x100da5800



lldb traces:

(lldb) attach emacs

Process 79773 stopped

* thread #1: tid = 0x6c3b4f, 0x00007fff8deb9166
libsystem_kernel.dylib`__psynch_mutexwait + 10, queue =
'com.apple.main-thread', stop reason = signal SIGSTOP

    frame #0: 0x00007fff8deb9166 libsystem_kernel.dylib`__psynch_mutexwait + 10

libsystem_kernel.dylib`__psynch_mutexwait:

->  0x7fff8deb9166 <+10>: jae    0x7fff8deb9170            ; <+20>

    0x7fff8deb9168 <+12>: movq   %rax, %rdi

    0x7fff8deb916b <+15>: jmp    0x7fff8deb4c53            ; cerror_nocancel

    0x7fff8deb9170 <+20>: retq


Executable module set to "/opt/local/bin/emacs".

Architecture set to: x86_64h-apple-macosx.

(lldb) thread backtrace all

* thread #1: tid = 0x6c3b4f, 0x00007fff8deb9166
libsystem_kernel.dylib`__psynch_mutexwait + 10, queue =
'com.apple.main-thread', stop reason = signal SIGSTOP

  * frame #0: 0x00007fff8deb9166 libsystem_kernel.dylib`__psynch_mutexwait + 10

    frame #1: 0x00007fff88a0d696
libsystem_pthread.dylib`_pthread_mutex_lock + 480

    frame #2: 0x0000000100a17b48 libglib-2.0.0.dylib`g_mutex_lock + 26

    frame #3: 0x00000001009d9b53
libglib-2.0.0.dylib`g_main_context_acquire + 109

    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: 0x00007fff8a6d25c9 libdyld.dylib`start + 1

    frame #18: 0x00007fff8a6d25c9 libdyld.dylib`start + 1

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

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

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

    frame #2: 0x00000001009dd07c
libglib-2.0.0.dylib`g_main_context_iterate + 845

    frame #3: 0x00000001009dd1b1
libglib-2.0.0.dylib`g_main_context_iteration + 127

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

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

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

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

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


Inkscape is the only other binary linked to glib that is running, I think:

Maneeshs-MacBook-Air:~ maneeshyadav$ ps

  PID TTY           TIME CMD

49116 ttys000    0:00.14 -bash

79773 ttys000    2:16.74 emacs

49772 ttys001    0:01.80 -bash

63245 ttys002    0:00.56 -bash

65082 ttys002    0:00.01 /bin/bash
/Applications/ChemAxon/MarvinBeans/bin/msketch

65087 ttys002   18:31.79
/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/bin/java
chemaxon.marvin.Sketch

81099 ttys002    1:06.60 inkscape

On Wed, Nov 25, 2015 at 10:49 AM, Maneesh Yadav <maneeshkyadav@gmail.com> wrote:
> 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

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

[John Wiegley]

>>>>> Maneesh Yadav <maneeshkyadav@gmail.com> writes:

> Apologies to all I haven't ben able to follow up on this more thoroughly,
> part of the problem was trying to get the crash to replicate. I could do it
> in a few minutes while I was originally posting, then as I was getting all
> the right debug statements in it got harder and harder. I decided to just
> revert to normal use and wait for it to happen. Just happened again and I've
> put all the debugging info I can here and will try to trace through glib and
> figure out what is going on, just putting everything here for reference.

That sure looks like a lot of locks for the same context. Now, I wonder how
could allow that code path to recur without intervening unlocks, as there were
before the hang?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

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

[Stefan Kangas]

Maneesh Yadav <maneeshkyadav@gmail.com> writes:

> Apologies to all I haven't ben able to follow up on this more
> thoroughly, part of the problem was trying to get the crash to
> replicate.  I could do it in a few minutes while I was originally
> posting, then as I was getting all the right debug statements in it
> got harder and harder.  I decided to just revert to normal use and
> wait for it to happen.  Just happened again and I've put all the
> debugging info I can here and will try to trace through glib and
> figure out what is going on, just putting everything here for
> reference.

(That was five years ago.)

Were you ever able to get any further in debugging this?  Are you still
seeing this on a recent version of Emacs?

Thanks in advance.

Best regards,
Stefan Kangas

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

[Maneesh Yadav]

[-- Attachment #1: Type: text/plain, Size: 949 bytes --]

Indeed. Fwiw haven't run into it since that era.

On Sun, Aug 30, 2020, 7:11 PM Stefan Kangas <stefan@marxist.se> wrote:

> Maneesh Yadav <maneeshkyadav@gmail.com> writes:
>
> > Apologies to all I haven't ben able to follow up on this more
> > thoroughly, part of the problem was trying to get the crash to
> > replicate.  I could do it in a few minutes while I was originally
> > posting, then as I was getting all the right debug statements in it
> > got harder and harder.  I decided to just revert to normal use and
> > wait for it to happen.  Just happened again and I've put all the
> > debugging info I can here and will try to trace through glib and
> > figure out what is going on, just putting everything here for
> > reference.
>
> (That was five years ago.)
>
> Were you ever able to get any further in debugging this?  Are you still
> seeing this on a recent version of Emacs?
>
> Thanks in advance.
>
> Best regards,
> Stefan Kangas
>

[-- Attachment #2: Type: text/html, Size: 1401 bytes --]

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

[Stefan Kangas]

Maneesh Yadav <maneeshkyadav@gmail.com> writes:

> Indeed. Fwiw haven't run into it since that era.

Thanks.  I'm therefore closing this bug report.

If you see something like this again, please open a new bug.