Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!abcfd20.larc.nasa.gov!lll-winken!uunet!bellcore!bae!aw
From: aw@bae.bae.bellcore.com (Andrew Wason)
Newsgroups: comp.windows.x
Subject: xmh bug
Message-ID: <1990Dec11.172238.29967@bellcore.bellcore.com>
Date: 11 Dec 90 17:22:38 GMT
Sender: usenet@bellcore.bellcore.com (Poster of News)
Reply-To: aw@cellar.bae.bellcore.com
Organization: Bell Communications Research
Lines: 60


Since I installed fix-18, xmh often core dumps in the following situation:

  Select a message in the Toc
  Select "Edit Message" from the "View" menu
  Perform a simple editing command in the message
  Select "Save Message" from the "View" menu
  Select "Edit Message" from the "View" menu
  Perform a simple editing command in the message
  Select "Save Message" from the "View" menu

Xmh usually core dumps at this point.
The stack trace is:

  CoreSetValues() at 0xf76f53bc
  CallSetValues() at 0xf7708174
  CallSetValues() at 0xf7708144
  CallSetValues() at 0xf7708144
  CallSetValues() at 0xf7708144
  XtSetValues() at 0xf7708484
  DoSaveView() at 0x10c00
  _XtCallCallbacks() at 0xf76f0998
  XtCallCallbacks() at 0xf76f0ba0
  `Sme`Notify() at 0xf777d3b0
  `SimpleMenu`Notify() at 0xf777c898
  _XtTranslateEvent() at 0xf770fe10
  DispatchEvent() at 0xf76f8ee8
  DecideToDispatch() at 0xf76f9618
  XtDispatchEvent() at 0xf76f96d8
  main() at 0x5594

This looks like the same problem xrn 6.13 has.
Both xmh and xrn do a get_values on a widgets XtNtranslations resource.
Xmh does a get_values on the view widgets XtNtranslations and saves
this translation table, then it installs some accelerators
and does another get_values to get the modified translation table
which it also saves.  Then when the user switches between edit
and read mode, xmh does a set_values on one or the other of the
previously saved translation tables.  Xrn does something similar
to this.  The problem is, as of fix-18 widgets appear to
modify their old translation table when a new one is installed.
This invalidates xmh's saved translation tables, and so it
eventually does a set_values with one of these bad tables.

Is this a bug in the Intrinsics/Athena widgets or xmh?
Should widgets return a copy of their translation table
on a get_values (that would fix xmh/xrn)?
Should applications treat XtNtranslations as a private
widget resource and never do a get_values on it (since the
widget could modify it at any time behind the applications back)?

Thanks for any input,
Andrew

[ Sun Sparc1+, SunOS 4.1, MIT X11R4 fix-18 ]

--------------------------------------------------------------------------------
Andrew Wason                                        Bell Communications Research
aw@cellar.bae.bellcore.com                          Piscataway, NJ
bellcore!cellar!aw