bug#53871: 29.0.50; Emacs freezes with new child-frame option

bug#53871: 29.0.50; Emacs freezes with new child-frame option

[Arash Esbati]

Hi all,

I'm trying the new option child-frame available for
`show-paren-context-when-offscreen' (introduced in 6e5d79c048) and I'm
running into an issue where Emacs freezes.  Steps to trigger:

1) emacs -Q
2) eval (setq show-paren-context-when-offscreen t) in scratch
3) M-x find-library RET paren RET
4) M-g c 13902 RET
5) With the mouse cursor, grab the scroll bar and move down so far to
   get the context
   'Matches (defun show-paren--show-context-in-child-frame (text)'
   in the echo area.
6) eval (setq show-paren-context-when-offscreen 'child-frame) in scratch
7) Repeat 5) and Emacs freezes

This is with repo-version 90eb6a7fe4 on Win10.

Best, Arash

bug#53871: 29.0.50; Emacs freezes with new child-frame option

[Tassilo Horn]

Arash Esbati <arash@gnu.org> writes:

Hi Arash,

> I'm trying the new option child-frame available for
> `show-paren-context-when-offscreen' (introduced in 6e5d79c048) and I'm
> running into an issue where Emacs freezes.  Steps to trigger:
>
> 1) emacs -Q
> 2) eval (setq show-paren-context-when-offscreen t) in scratch
> 3) M-x find-library RET paren RET
> 4) M-g c 13902 RET
> 5) With the mouse cursor, grab the scroll bar and move down so far to
>    get the context
>    'Matches (defun show-paren--show-context-in-child-frame (text)'
>    in the echo area.
> 6) eval (setq show-paren-context-when-offscreen 'child-frame) in scratch
> 7) Repeat 5) and Emacs freezes
>
> This is with repo-version 90eb6a7fe4 on Win10.

I can't reproduce with the slightly later version 9d1ae05442 on
GNU/Linux with a pgtk build.  When scroll up and down (only so far as to
keep point at the closing paren of the defun), I'll see the child frame
displaying the "(defun ...)" line whenever I stop scrolling for a
second.

After doing that for I while, I checked that `(frame-list)` still
contains just a single frame.  How is that for you?  Do you have many
frames in there?  And do you recover from the freeze?

Does doing the recipe with debug-on-quit set and then doing C-g when the
freeze occurs shed some light?

Bye,
Tassilo

bug#53871: 29.0.50; Emacs freezes with new child-frame option

[Arash Esbati]

Hi Tassilo,

Tassilo Horn <tsdh@gnu.org> writes:

> I can't reproduce with the slightly later version 9d1ae05442 on
> GNU/Linux with a pgtk build.  When scroll up and down (only so far as to
> keep point at the closing paren of the defun), I'll see the child frame
> displaying the "(defun ...)" line whenever I stop scrolling for a
> second.
>
> After doing that for I while, I checked that `(frame-list)` still
> contains just a single frame.  How is that for you?

Thanks for your response.  It is the same, only one frame.

> And do you recover from the freeze?

No recovery, Emacs freezes hard and I have to kill it from the shell.

> Does doing the recipe with debug-on-quit set and then doing C-g when the
> freeze occurs shed some light?

See above.  Interesting point is that scrolling with mouse wheel isn't a
problem, things play havoc if I touch the scroll bar with the mouse
pointer.

Best, Arash

bug#53871: 29.0.50; Emacs freezes with new child-frame option

[Tassilo Horn]

Arash Esbati <arash@gnu.org> writes:

>> After doing that for I while, I checked that `(frame-list)` still
>> contains just a single frame.  How is that for you?
>
> Thanks for your response.  It is the same, only one frame.

Hm, `frame-list' says it doesn't return "tooltip frames".  I think
that's something else than child frames but you might try
`(frames-on-display-list)', too.  It should also return a single frame
unless a show-paren child-frame is still visible.

>> And do you recover from the freeze?
>
> No recovery, Emacs freezes hard and I have to kill it from the shell.

Could you get a backtrace with GDB?  Basically just

  $ gdb src/emacs -x src/.gdbinit
  > run
  # do your scroll stuff until it freezes and then hit C-z in gdb and do
  > xbacktrace # get a lisp backtrace
  > bt full    # get a C backtrace

The C backtrace is probably large so please compress is before attaching
it here.

>> Does doing the recipe with debug-on-quit set and then doing C-g when
>> the freeze occurs shed some light?
>
> See above.  Interesting point is that scrolling with mouse wheel isn't
> a problem, things play havoc if I touch the scroll bar with the mouse
> pointer.

Could you put a message in show-paren--show-context-in-child-frame just
to get a feeling of how often a child frame is created?

Bye,
Tassilo

bug#53871: 29.0.50; Emacs freezes with new child-frame option

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Date: Tue, 08 Feb 2022 11:35:17 +0100
> Cc: 53871@debbugs.gnu.org
> 
> > 1) emacs -Q
> > 2) eval (setq show-paren-context-when-offscreen t) in scratch
> > 3) M-x find-library RET paren RET
> > 4) M-g c 13902 RET
> > 5) With the mouse cursor, grab the scroll bar and move down so far to
> >    get the context
> >    'Matches (defun show-paren--show-context-in-child-frame (text)'
> >    in the echo area.
> > 6) eval (setq show-paren-context-when-offscreen 'child-frame) in scratch
> > 7) Repeat 5) and Emacs freezes
> >
> > This is with repo-version 90eb6a7fe4 on Win10.
> 
> I can't reproduce with the slightly later version 9d1ae05442 on
> GNU/Linux with a pgtk build.  When scroll up and down (only so far as to
> keep point at the closing paren of the defun), I'll see the child frame
> displaying the "(defun ...)" line whenever I stop scrolling for a
> second.
> 
> After doing that for I while, I checked that `(frame-list)` still
> contains just a single frame.  How is that for you?  Do you have many
> frames in there?  And do you recover from the freeze?

The number of the frames is not the problem.  Yes, there's just one
frame on Windows as well.  And no, there's no way to recover, because
the implementation of this feature seems to cause on MS-Windows a
deadlock between two threads, one of which is the main thread.

On Windows, creating a frame involves sending a message to a separate
UI thread and waiting for that thread to respond, but in this
scenario, doing that seems to lead to some kind of deadlock, whereby
both threads wait for messages.

Martin, any ideas?  I can show the backtrace from the freeze, if that
helps.

bug#53871: 29.0.50; Emacs freezes with new child-frame option

[martin rudalics]

 > Martin, any ideas?  I can show the backtrace from the freeze, if that
 > helps.

No ideas.  I also observed that the scroll bar in the main frame must be
involved.  Mouse-wheel scrolling doesn't freeze it here either.  So we
seem to have two competing windows - the scroll bar window and the child
frame window - which we would have to disentangle somehow.

martin

bug#53871: 29.0.50; Emacs freezes with new child-frame option

[Eli Zaretskii]

> Date: Tue, 8 Feb 2022 19:23:21 +0100
> Cc: arash@gnu.org, 53871@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
>  > Martin, any ideas?  I can show the backtrace from the freeze, if that
>  > helps.
> 
> No ideas.  I also observed that the scroll bar in the main frame must be
> involved.  Mouse-wheel scrolling doesn't freeze it here either.  So we
> seem to have two competing windows - the scroll bar window and the child
> frame window - which we would have to disentangle somehow.

How come we don't see something similar in any other code that creates
child frames?  Scrolling via the scroll bars is possible while some
Lisp creates child frames not necessarily in this context.  Are our
frame creation so fragile that it doesn't tolerate scroll bars in
parallel with frame creation?

bug#53871: 29.0.50; Emacs freezes with new child-frame option

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> How come we don't see something similar in any other code that creates
> child frames?  Scrolling via the scroll bars is possible while some
> Lisp creates child frames not necessarily in this context.  Are our
> frame creation so fragile that it doesn't tolerate scroll bars in
> parallel with frame creation?

FWIW, I don't think it's a bug in our generic frame creation code since
I can't reproduce the bug on Haiku, where there is a thread for each
window, and we do a similar dance with sending messages to them from the
main thread and waiting for replies.

bug#53871: 29.0.50; Emacs freezes with new child-frame option

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: martin rudalics <rudalics@gmx.at>,  arash@gnu.org,
>   53871@debbugs.gnu.org,  tsdh@gnu.org
> Date: Wed, 09 Feb 2022 08:41:49 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > How come we don't see something similar in any other code that creates
> > child frames?  Scrolling via the scroll bars is possible while some
> > Lisp creates child frames not necessarily in this context.  Are our
> > frame creation so fragile that it doesn't tolerate scroll bars in
> > parallel with frame creation?
> 
> FWIW, I don't think it's a bug in our generic frame creation code

I didn't say it was.  The problem is definitely specific to
MS-Windows, as I tried to explain up-thread.