GNU bug report logs - #59733
29.0.50; unrespnsive Xaw menus

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 59733 in the body.
You can then email your comments to 59733 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Madhu <enometh <at> meer.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; unrespnsive Xaw menus
Date: Thu, 01 Dec 2022 08:05:17 +0530 (IST)

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

* c0fa3f2a6b8ce06af59f5e70cf1757189bd401f0
| Author: Po Lu <luangruo <at> yahoo.com>  2022-02-17 15:31:30
| Committer: Po Lu <luangruo <at> 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

Message #8 received at 59733 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Madhu <enometh <at> meer.net>
Cc: 59733 <at> debbugs.gnu.org
Subject: Re: bug#59733: 29.0.50; unrespnsive Xaw menus
Date: Thu, 01 Dec 2022 15:17:21 +0800

Madhu <enometh <at> 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 <at> yahoo.com>  2022-02-17 15:31:30
> | Committer: Po Lu <luangruo <at> 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'?

Message #11 received at 59733 <at> debbugs.gnu.org (full text, mbox):

From: Madhu <enometh <at> meer.net>
To: luangruo <at> yahoo.com
Cc: 59733 <at> debbugs.gnu.org
Subject: Re: bug#59733: 29.0.50; unrespnsive Xaw menus
Date: Thu, 01 Dec 2022 15:04:14 +0530 (IST)

*  Po Lu <87edtjtwxq.fsf <at> 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)

Message #14 received at 59733 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Madhu <enometh <at> meer.net>
Cc: 59733 <at> debbugs.gnu.org
Subject: Re: bug#59733: 29.0.50; unrespnsive Xaw menus
Date: Thu, 01 Dec 2022 18:10:07 +0800

Madhu <enometh <at> 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?

Message #17 received at 59733 <at> debbugs.gnu.org (full text, mbox):

From: Madhu <enometh <at> meer.net>
To: luangruo <at> yahoo.com
Cc: 59733 <at> debbugs.gnu.org
Subject: Re: bug#59733: 29.0.50; unrespnsive Xaw menus
Date: Thu, 01 Dec 2022 18:26:24 +0530 (IST)

*  Po Lu <87a647toxs.fsf <at> 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?)

Message #20 received at 59733 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Madhu <enometh <at> meer.net>
Cc: 59733 <at> debbugs.gnu.org
Subject: Re: bug#59733: 29.0.50; unrespnsive Xaw menus
Date: Thu, 01 Dec 2022 21:11:52 +0800

Madhu <enometh <at> 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.

Message #23 received at 59733 <at> debbugs.gnu.org (full text, mbox):

From: Visuwesh <visuweshm <at> gmail.com>
To: Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
 editors" <luangruo <at> yahoo.com>
Cc: 59733 <at> debbugs.gnu.org, Madhu <enometh <at> meer.net>
Subject: Re: bug#59733: 29.0.50; unrespnsive Xaw menus
Date: Thu, 01 Dec 2022 19:25:36 +0530

forcemerge 57320 59733
thanks

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

> Madhu <enometh <at> 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.

Message #28 received at 59733 <at> debbugs.gnu.org (full text, mbox):

From: Madhu <enometh <at> meer.net>
To: luangruo <at> yahoo.com
Cc: 59733 <at> debbugs.gnu.org
Subject: Re: bug#59733: 29.0.50; unrespnsive Xaw menus
Date: Thu, 01 Dec 2022 19:54:27 +0530 (IST)

*  Po Lu <87v8mvs1yf.fsf <at> 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.

Message #31 received at 59733 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Madhu <enometh <at> meer.net>
Cc: 59733 <at> debbugs.gnu.org
Subject: Re: bug#59733: 29.0.50; unrespnsive Xaw menus
Date: Fri, 02 Dec 2022 09:04:39 +0800

Madhu <enometh <at> 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?

Message #34 received at 59733 <at> debbugs.gnu.org (full text, mbox):

From: Madhu <enometh <at> meer.net>
To: luangruo <at> yahoo.com
Cc: 59733 <at> debbugs.gnu.org
Subject: Re: bug#59733: 29.0.50; unrespnsive Xaw menus
Date: Sun, 04 Dec 2022 10:54:22 +0530 (IST)

*  Po Lu <87mt86sjiw.fsf <at> 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 <at> entry=0xfc5fa0, owner_events=owner_events <at> entry=0 '\000', event_mask=event_mask <at> entry=204, pointer_mode=pointer_mode <at> entry=1, keyboard_mode=keyboard_mode <at> entry=1, confine_to=confine_to <at> 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 <at> entry=0,
    event_mask=event_mask <at> entry=204,
    pointer_mode=pointer_mode <at> entry=1,
    keyboard_mode=keyboard_mode <at> 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 <at> entry=0xfc5fa0, owner_events=owner_events <at> entry=0 '\000', pointer_mode=pointer_mode <at> entry=1, keyboard_mode=1, event_mask=event_mask <at> 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)

Message #37 received at 59733 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Madhu <enometh <at> meer.net>
Cc: 59733 <at> debbugs.gnu.org
Subject: Re: bug#59733: 29.0.50; unrespnsive Xaw menus
Date: Sun, 04 Dec 2022 14:36:59 +0800

Madhu <enometh <at> 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.

Message #40 received at 59733 <at> debbugs.gnu.org (full text, mbox):

From: Madhu <enometh <at> meer.net>
To: luangruo <at> yahoo.com
Cc: 59733 <at> debbugs.gnu.org
Subject: Re: bug#59733: 29.0.50; unresponsive Xaw menus
Date: Mon, 05 Dec 2022 13:35:09 +0530 (IST)

*  Po Lu <87mt83r7xw.fsf <at> 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

Message #43 received at 59733 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Madhu <enometh <at> meer.net>
Cc: 59733 <at> debbugs.gnu.org
Subject: Re: bug#59733: 29.0.50; unresponsive Xaw menus
Date: Mon, 05 Dec 2022 16:58:13 +0800

Madhu <enometh <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.