bug#59733: 29.0.50; unrespnsive Xaw menus

bug#59733: 29.0.50; unrespnsive Xaw menus

[Madhu]

Xaw3d menus (both menubar and pop-up menus) have been unresponsive to
mouse moves since commit c0fa3f2a6b8ce06af5

* c0fa3f2a6b8ce06af59f5e70cf1757189bd401f0
| Author: Po Lu <luangruo@yahoo.com>  2022-02-17 15:31:30
| Committer: Po Lu <luangruo@yahoo.com>  2022-02-17 15:36:12
|    Prevent menu items leak if x-pre-popup-menu-hook signals
|    * src/menu.c (x_popup_menu_1): Make sure menu items are
|    discarded if the pre popup menu hook signals.

This is on non-NS an --with-x-toolkit=athena build. to reproduce, bring
up a pop-up-menu by clicking on a menubar item, or by pressing Shift F10
and choosing a submenu.  none of the pop-up-menu items in the submenu
are responsive to mouse selection.

It appearsAfter the change a necessary discard_menu_items call does not
seem to be happening in src.c: (x_popup_menu_1)


In GNU Emacs 29.0.50 (build 11, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.16.0, Xaw3d scroll bars) of 2022-10-20 built on maher
Repository revision: dda57221b1163b4223add47f172c9dd8d2826a15
Repository branch: madhu-tip
Windowing system distributor 'The X.Org Foundation', version 11.0.12101003
System Description: Gentoo/Linux

Configured using:
 'configure -C --with-x-toolkit=athena --with-native-compilation
 --with-xinput2'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3
THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XAW3D XDBE XIM XINPUT2 XPM
LUCID ZLIB

bug#59733: 29.0.50; unrespnsive Xaw menus

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

Madhu <enometh@meer.net> writes:

> Xaw3d menus (both menubar and pop-up menus) have been unresponsive to
> mouse moves since commit c0fa3f2a6b8ce06af5
>
> * c0fa3f2a6b8ce06af59f5e70cf1757189bd401f0
> | Author: Po Lu <luangruo@yahoo.com>  2022-02-17 15:31:30
> | Committer: Po Lu <luangruo@yahoo.com>  2022-02-17 15:36:12
> |    Prevent menu items leak if x-pre-popup-menu-hook signals
> |    * src/menu.c (x_popup_menu_1): Make sure menu items are
> |    discarded if the pre popup menu hook signals.
>
> This is on non-NS an --with-x-toolkit=athena build. to reproduce, bring
> up a pop-up-menu by clicking on a menubar item, or by pressing Shift F10
> and choosing a submenu.  none of the pop-up-menu items in the submenu
> are responsive to mouse selection.
>
> It appearsAfter the change a necessary discard_menu_items call does not
> seem to be happening in src.c: (x_popup_menu_1)

Did you find this through `git bisect'?

bug#59733: 29.0.50; unrespnsive Xaw menus

[Madhu]

*  Po Lu <87edtjtwxq.fsf@yahoo.com>
Wrote on Thu, 01 Dec 2022 15:17:21 +0800
> Did you find this through `git bisect'?

argh you got me :) no, I just looked for commits after a version (from
2021) where it worked, and reverting this fixed it.
(apparently I haven't used any menus in the whole period)

bug#59733: 29.0.50; unrespnsive Xaw menus

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

Madhu <enometh@meer.net> writes:

> argh you got me :) no, I just looked for commits after a version (from
> 2021) where it worked, and reverting this fixed it.
> (apparently I haven't used any menus in the whole period)

If you run "make extraclean" and then rebuild Emacs, is it still fixed?

bug#59733: 29.0.50; unrespnsive Xaw menus

[Madhu]

*  Po Lu <87a647toxs.fsf@yahoo.com>
> If you run "make extraclean" and then rebuild Emacs, is it still fixed?

I did did a new checkout of the latest master and did a build and I
don't see the bug. i.e. menus work as expected.  I should've checked
before reporting.

I believe this bug can be closed, thanks, (but I'm still curious: why
do you think I am seeing the bad behaviour on the
tree-with-previous-build-artefacts I that I have?)

bug#59733: 29.0.50; unrespnsive Xaw menus

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

Madhu <enometh@meer.net> writes:

> I did did a new checkout of the latest master and did a build and I
> don't see the bug. i.e. menus work as expected.  I should've checked
> before reporting.
>
> I believe this bug can be closed, thanks, (but I'm still curious: why
> do you think I am seeing the bad behaviour on the
> tree-with-previous-build-artefacts I that I have?)

No, I think this is a duplicate of the Lucid menu heisenbug (our
``athena'' build is actually just an alias for the Lucid build.)

That bug has eluded debugging by over 4 people in this fashion.  Would
someone please find that bug and merge this one with it?

Thanks in advance.

bug#59733: 29.0.50; unrespnsive Xaw menus

[Visuwesh]

forcemerge 57320 59733
thanks

[வியாழன் டிசம்பர் 01, 2022] Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:

> Madhu <enometh@meer.net> writes:
>
>> I did did a new checkout of the latest master and did a build and I
>> don't see the bug. i.e. menus work as expected.  I should've checked
>> before reporting.
>>
>> I believe this bug can be closed, thanks, (but I'm still curious: why
>> do you think I am seeing the bad behaviour on the
>> tree-with-previous-build-artefacts I that I have?)
>
> No, I think this is a duplicate of the Lucid menu heisenbug (our
> ``athena'' build is actually just an alias for the Lucid build.)
>
> That bug has eluded debugging by over 4 people in this fashion.  Would
> someone please find that bug

The first in that series is bug#57320 IIRC.

> and merge this one with it?

I hope I did that correctly.

> Thanks in advance.

bug#59733: 29.0.50; unrespnsive Xaw menus

[Madhu]

*  Po Lu <87v8mvs1yf.fsf@yahoo.com>
>
> That bug has eluded debugging by over 4 people in this fashion.  Would
> someone please find that bug and merge this one with it?

Thanks Visuwesh has "merged" #57320, #58518 and this #57933.

I still have the build directory which was failing.  If I revert
c0fa3f2a6b8 the lucid menu works. If I put it back in, the menu stops
working.  Perhaps this commit might still suggest where the problem
is.

bug#59733: 29.0.50; unrespnsive Xaw menus

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

Madhu <enometh@meer.net> writes:

> I still have the build directory which was failing.  If I revert
> c0fa3f2a6b8 the lucid menu works. If I put it back in, the menu stops
> working.  Perhaps this commit might still suggest where the problem
> is.

Well, could you please do what I asked in the other reports?  Namely, to
put a breakpoint on the call to XtGrabKeyboard on xlwmenu.c, and see
what it returns, from another machine?

bug#59733: 29.0.50; unrespnsive Xaw menus

[Madhu]

*  Po Lu <87mt86sjiw.fsf@yahoo.com>
Wrote on Fri, 02 Dec 2022 09:04:39 +0800
> Well, could you please do what I asked in the other reports?  Namely, to
> put a breakpoint on the call to XtGrabKeyboard on xlwmenu.c, and see
> what it returns, from another machine?

[Maybe this can be done on the same machine with xpra. Right now I'm
set up walking between two rooms...  it's tricky as the frame display
can lock up and the process has to be killed.]

(gdb) r
Starting program: /12/build/emacs/build-xt/src/emacs -Q
(gdb) sharedlib libXaw
(gdb) sharedlib libX11
(gdb) b xlwmenu.c:2879
Breakpoint 3 at 0x68f973: file ../../lwlib/xlwmenu.c, line 2879.
(gdb) c
Continuing.
Thread 1 "emacs" hit Breakpoint 3, pop_up_menu (event=0xea2ba0, mw=0xfc5fa0) at ../../lwlib/xlwmenu.c:2879
2879      if (XtGrabPointer ((Widget)mw, False,
(gdb) s
XtGrabPointer (widget=widget@entry=0xfc5fa0, owner_events=owner_events@entry=0 '\000', event_mask=event_mask@entry=204, pointer_mode=pointer_mode@entry=1, keyboard_mode=keyboard_mode@entry=1, confine_to=confine_to@entry=0, cursor=33554483, time=224367550) at /usr/src/debug/x11-libs/libXt-1.2.1/libXt-1.2.1/src/PassivGrab.c:993
993         WIDGET_TO_APPCON(widget);
(gdb) s
(gdb) finish
Run till exit from #0  XGrabPointer (dpy=0xdf4980,
    grab_window=33554493, owner_events=owner_events@entry=0,
    event_mask=event_mask@entry=204,
    pointer_mode=pointer_mode@entry=1,
    keyboard_mode=keyboard_mode@entry=1, confine_to=0, curs=33554483,
    time=224367550)
    at /usr/src/debug/x11-libs/libX11-1.8.1/libX11-1.8.1/src/GrPointer.c:47
GrabDevice (widget=widget@entry=0xfc5fa0, owner_events=owner_events@entry=0 '\000', pointer_mode=pointer_mode@entry=1, keyboard_mode=1, event_mask=event_mask@entry=204, confine_to=0, cursor=33554483, time=224367550, isKeyboard=0 '\000') at /usr/src/debug/x11-libs/libXt-1.2.1/libXt-1.2.1/src/PassivGrab.c:895
895         if (returnVal == GrabSuccess) {
Value returned is $2 = 0


The upshot is XtGrabPointer returns 0 and the menu becomes unresponsive[1]

When it works, i.e. when XtGrabPointer returns True, It seems I'm not
able to step into XtGrabPointer as `s' puts me on the next line of
pop_up_menu.

This is a heads up, if you have further instructions.

PS (can the typo in the Subject line be fixed)

bug#59733: 29.0.50; unrespnsive Xaw menus

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

Madhu <enometh@meer.net> writes:

> [Maybe this can be done on the same machine with xpra. Right now I'm
> set up walking between two rooms...  it's tricky as the frame display
> can lock up and the process has to be killed.]

You're welcome to try, but my gut feeling is that it won't work.  Thanks
for going through all that trouble to debug this!

> The upshot is XtGrabPointer returns 0 and the menu becomes unresponsive[1]
>
> When it works, i.e. when XtGrabPointer returns True, It seems I'm not
> able to step into XtGrabPointer as `s' puts me on the next line of
> pop_up_menu.

If XtGrabPointer returns a non-zero value, then it means obtaining the
grab failed.  Exactly which non-zero value does it return?  Do the menus
start working if you comment out the call to "XtGrabPointer" entirely?

The relevant return codes are:

        #define GrabSuccess		0
        #define AlreadyGrabbed		1
        #define GrabInvalidTime		2
        #define GrabNotViewable		3
        #define GrabFrozen		4

> PS (can the typo in the Subject line be fixed)

Yes, as long as you keep the "bug#" intact.

bug#59733: 29.0.50; unresponsive Xaw menus

[Madhu]

*  Po Lu <87mt83r7xw.fsf@yahoo.com>
Wrote on Sun, 04 Dec 2022 14:36:59 +0800
> If XtGrabPointer returns a non-zero value, then it means obtaining the
> grab failed.  Exactly which non-zero value does it return?  Do the menus
> start working if you comment out the call to "XtGrabPointer" entirely?
>
> The relevant return codes are:
>
>         #define GrabSuccess		0
>         #define AlreadyGrabbed		1
>         #define GrabInvalidTime		2
>         #define GrabNotViewable		3
>         #define GrabFrozen		4
>
>> PS (can the typo in the Subject line be fixed)
>
> Yes, as long as you keep the "bug#" intact.

Thanks, unfortunately this looks like a genuine heisenbug and my
earlier reports should be deemed unreliable.  I do have builds which
"don't work" but I'm am now unable to produce *new* builds which
"don't work", (say with adding printf debugging or resetting)

AFAICT both XtGrabPointer and XtGrabKeyboard return Success in all
cases (both "works" and "doesn't work" builds) - keyboard and pointer
are both grabbed as expected - from gdb dprintfs, disassembly seems
identical.

The only significant thing I can report (I have libinput
enable-tab=true) on a "doesn't work" build is that if i quickly make
two single taps on the help button on the toolbar, on the touchpad,
then the pop-up-menu "works".  (the effect seems to be an event
between the activation of the menu and the display of the menu - F10
doesn't work as usual). There hasn't been any progress Sorry

bug#59733: 29.0.50; unresponsive Xaw menus

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

Madhu <enometh@meer.net> writes:

> Thanks, unfortunately this looks like a genuine heisenbug and my
> earlier reports should be deemed unreliable.  I do have builds which
> "don't work" but I'm am now unable to produce *new* builds which
> "don't work", (say with adding printf debugging or resetting)
>
> AFAICT both XtGrabPointer and XtGrabKeyboard return Success in all
> cases (both "works" and "doesn't work" builds) - keyboard and pointer
> are both grabbed as expected - from gdb dprintfs, disassembly seems
> identical.
>
> The only significant thing I can report (I have libinput
> enable-tab=true) on a "doesn't work" build is that if i quickly make
> two single taps on the help button on the toolbar, on the touchpad,
> then the pop-up-menu "works".  (the effect seems to be an event
> between the activation of the menu and the display of the menu - F10
> doesn't work as usual). There hasn't been any progress Sorry

This might be a stab in the dark, but:

Can you run both builds that "work" and those that "don't work" under
Valgrind and see if there is some memory problem causing this?

Make sure to run Emacs with "--eval (setq gc-cons-threshold
most-positive-fixnum)" specified on the command line, or false positives
will be reported during GC.