xterm dies on popup-menu action

It's unlikely to be the same bug.

More likely (since no one's reported anything recent - Ubuntu's
xterm is from last summer) is this item fixed in patch #263:

Patch #263 - 2010/10/13
corrected initialization of "misc" resource values, to ensure that xterm has allocated a copy of strings which may not have been malloc'd by the X library (Debian #600129).

Hey Owen,

Hi, have you had a chance to test if this bug is still present in natty?

If it does (and if you're the original reporter), please boot into natty
and run the command:

  apport-collect <bug-number>

which will update the bug with fresh logs and tag the bug as affecting
natty. (It is best to run this right after reproducing the problem.)

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Bug still occurring in natty, error messages exactly the same as before (except that serial number of failed request has changed, which I think is as it should be). xterm -version shows XTerm(268).

Perhaps your machine doesn't have the fonts used for the menus.
(None of the attachments or responses address this area, packagers
generally decline to add fonts as dependencies to xterm).

The fonts are there. I know this because I can use the various control-mouse button options to show the menus correctly. It is only when I try to perform the same action using a function key that the program crashes. For the record, I just want to use the function keys because control-mouse button is awkward, especially on a laptop with a touchpad and no mouse.

I see (now, having read through the changes, and made a test-case). The fix in #226
was for the core-dump. The report was for two errors, and one was not addressed.
I can see that it's dying in the call in menu.c
   XtCallActionProc(w, "XawPositionSimpleMenu", event, params, 1);

The widget itself is okay (commenting out that call makes it "work").
But the problem is in the Xaw library. Reading the source code, that
causes it to go into a case-statement where the normal event types
are ButtonPress, ButtonRelease, etc. None of the normal types apply;
it goes into a default case for
   PositionMenu(menu, NULL);
which asks it to get the child-window of the menu-widget which encloses
the pointer. However, the pointer is probably outside the menu widget
since it's pointing to the vt100 window. So the XQueryPointer call fails

I might be able to appease it by checking for this case and warping the
pointer onto the menu widget (will see).

thanks for the feedback

On Sat, Apr 30, 2011 at 12:02:06AM -0000, Thomas Dickey wrote:
> I might be able to appease it by checking for this case and warping the
> pointer onto the menu widget (will see).

This seems to work:

===================================================================
RCS file: RCS/menu.c,v
retrieving revision 1.289
diff -u -r1.289 menu.c
--- menu.c 2011/04/24 18:18:30 1.289
+++ menu.c 2011/04/30 00:22:23
@@ -834,10 +834,29 @@
 {
     TRACE(("HandlePopupMenu\n"));
     if (domenu(w, event, params, param_count)) {
+ XtermWidget xw = term;
+ TScreen *screen = TScreenOf(xw);
+
 #if OPT_TOOLBAR
  w = select_menu(w, mainMenu)->w;
 #endif
- XtCallActionProc(w, "XawPositionSimpleMenu", event, params, 1);
+ /*
+ * The action procedure in SimpleMenu.c, PositionMenu does not expect a
+ * key translation event when we are popping up a menu. In particular,
+ * if the pointer is outside the menu, then the action procedure will
+ * fail in its attempt to determine the location of the pointer within
+ * the menu. Anticipate that by warping the pointer into the menu when
+ * a key event is detected.
+ */
+ switch (event->type) {
+ case KeyPress:
+ case KeyRelease:
+ XWarpPointer(screen->display, None, XtWindow(w), 0, 0, 0, 0, 0, 0);
+ break;
+ default:
+ XtCallActionProc(w, "XawPositionSimpleMenu", event, params, 1);
+ break;
+ }
  XtCallActionProc(w, "MenuPopup", event, params, 1);
     }
 }

--
Thomas E. Dickey <email address hidden>
http://invisible-island.net
ftp://invisible-island.net

[Expired for xterm (Ubuntu) because there has been no activity for 60 days.]

This bug was fixed in the package xterm - 271-1ubuntu1

---------------
xterm (271-1ubuntu1) oneiric; urgency=low

  * Merge from Debian unstable (LP: #756273), remaining changes:
    - debian/patches/950_ubuntu_charclass_highlight.diff: Enabled URL
      highlighting
    - debian/patches/Add 951_uxterm_utf8_title.diff: Set utf8Titles to true by
      default when using uxterm, so that it displays utf8 directories in titles
      properly. May cause issues with apps that use control sequences for
      updating the xterm titlebar - users should use xterm or set utf8Title
      to false in this case.
    - debian/gbp.conf: Use "Ubuntu" in "debian-branch" directly
    - Install .desktop files.
  * control: Revert the change to Vcs headers.
  * xterm.overrides: Purge old utempter-reversal cruft.

xterm (271-1) unstable; urgency=low

  * New upstream release
    - amend change for Debian #110226 so that "-h" or "-v" options cause an
      exit, rather than simply printing to stdout while the window is
      displayed (closes: #629358)
    - handle special-case of KeyPress translated to popup-menu action
      (LP: #756273)
 -- Timo Aaltonen <email address hidden> Thu, 11 Aug 2011 15:04:15 +0300