[comp.windows.x] Problems with X11R4 public fix #12

dinah@WILKINS.BCM.TMC.EDU (Dinah Anderson) (06/28/90)

I applied this patch and did a make world and installed the 
new software and include files. Most of the clients that use the
Xt library would die and dump core. For example, xterm would startup,
but the second you tried to type anything in the window, the process would
die and dump core.

I backed out the changes and recompiled and everything now works ok. Did
anyone else have this problem?

Dinah Anderson					 Manager of Systems Integration
Baylor College of Medicine	                                 Houston, Texas
internet: dinah@bcm.tmc.edu                   uucp: {rutgers,mailrus}!bcm!dinah

envbvs@epb2.lbl.gov (Brian V. Smith) (06/29/90)

In article <9006271916.AA00839@NICOLLE.IAIMS.BCM.TMC.EDU>,
dinah@WILKINS.BCM.TMC.EDU (Dinah Anderson) writes:
|> 
|> I applied this patch and did a make world and installed the 
|> new software and include files. Most of the clients that use the
|> Xt library would die and dump core. For example, xterm would startup,
|> but the second you tried to type anything in the window, the process would
|> die and dump core.
|> 
|> I backed out the changes and recompiled and everything now works ok. Did
|> anyone else have this problem?
|> 
|> Dinah Anderson					 Manager of Systems
Integration
|> Baylor College of Medicine	                                 Houston, Texas
|> internet: dinah@bcm.tmc.edu                   uucp:
{rutgers,mailrus}!bcm!dinah

Yes!  Here is a core dump of xterm:
You get it when you type any character in it.

dbx xterm
dbx version 2.0 of 10/19/88 2:02.
Type 'help' for help.
reading symbolic information ...
(dbx) run -e bea

Bus error in _XtMatchUsingDontCareMods at 0x28c74
00028c74  movl  (r11),(r1)
(dbx) where
_XtMatchUsingDontCareMods(0x86484, 0x7fffda6c) at 0x28c74
MatchEvent(0x7eb84, 0x7fffda6c) at 0x28ec4
_XtTranslateEvent(0x84404, 0x84434, 0x7fffdf08, 0x7fffdad0) at 0x290e1
DispatchEvent(0x7fffdf08, 0x84404, 0x1, 0x66908) at 0x19981
DecideToDispatch(0x7fffdf08) at 0x19d2f
XtDispatchEvent(0x7fffdf08) at 0x19d9e
xevents() at 0xc1c1
in_put() at 0x36c9
VTparse() at 0x2866
VTRun() at 0x4987
main.main(0x2, 0x7fffe0ac, 0x7fffe0bc) at 0x892

_____________________________________
Brian V. Smith    (bvsmith@lbl.gov)
Lawrence Berkeley Laboratory
I don't speak for LBL, these non-opinions are all mine.

envbvs@epb2.lbl.gov (Brian V. Smith) (06/29/90)

Sorry, cardinal sin time.  I forgot to say:

gcc1.36, Vaxstation II Xqvss, Ultrix 3.0, X11R4 patches 1-12

gcc options: -fwritable-strings -fstrength-reduce -fpcc-struct-return
_____________________________________
Brian V. Smith    (bvsmith@lbl.gov)
Lawrence Berkeley Laboratory
I don't speak for LBL, these non-opinions are all mine.

rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (06/29/90)

    For example, xterm would startup,
    but the second you tried to type anything in the window, the process would
    die and dump core.

Hmm, I rebuilt the public patched Xt on both a DECstation 3100 (cc)
and a VAXstation 3100 (gcc), and linked xterms with them, and both
xterms seemd to work just fine.  Beats me.  Has anyone gotten fix-12 to
work?  Is anyone else having problems?  (If others are, I'll probably
withdraw it until something gets resolved.)

evans@decvaxdec.com (Marc Evans) (06/29/90)

In article <9006282345.AA22953@expire.lcs.mit.edu>, rws@EXPO.LCS.MIT.EDU
(Bob Scheifler) writes:
|> Has anyone gotten fix-12 to
|> work?  Is anyone else having problems?  (If others are, I'll probably
|> withdraw it until something gets resolved.)

I have applied the patch without error top the sources, built using
'make World'
(I didn't have objects around still), and installed the result onto a PMAX. It
has been running for about 3 days now without any problems. Also, I have
rebuilt
many clients not included in the *statdard* MIT distribution which also work
fine. Therefore, at least from the PMAX perspective, I don't think the patch
should be withdrawn...

- Marc
===========================================================================
Marc Evans - WB1GRH - evans@decvax.DEC.COM  | Synergytics     (603)635-8876
      Unix and X Software Contractor        | 21 Hinds Ln, Pelham, NH 03076
===========================================================================

jody@shell.COM (Jody Winston) (06/29/90)

I've gotten fix-12 to work on Sun4s OS 4.0.3 using cc.

envbvs@EPB2.LBL.GOV (Brian V. Smith) (06/29/90)

me:

	    For example, xterm would startup,
	    but the second you tried to type anything in the window, the process would
	    die and dump core.
	
Bob:

	Hmm, I rebuilt the public patched Xt on both a DECstation 3100 (cc)
	and a VAXstation 3100 (gcc), and linked xterms with them, and both
	xterms seemd to work just fine.  Beats me.  Has anyone gotten fix-12 to
	work?  Is anyone else having problems?  (If others are, I'll probably
	withdraw it until something gets resolved.)
	
I'll try it on our 4/280 with cc and see what happens.

Brian

envbvs@epb2.lbl.gov (Brian V. Smith) (06/29/90)

In article <9006282345.AA22953@expire.lcs.mit.edu>, rws@EXPO.LCS.MIT.EDU
(Bob Scheifler) writes:
|> 
|>     For example, xterm would startup,
|>     but the second you tried to type anything in the window, the
process would
|>     die and dump core.
|> 
|> Hmm, I rebuilt the public patched Xt on both a DECstation 3100 (cc)
|> and a VAXstation 3100 (gcc), and linked xterms with them, and both
|> xterms seemd to work just fine.  Beats me.  Has anyone gotten fix-12 to
|> work?  Is anyone else having problems?  (If others are, I'll probably
|> withdraw it until something gets resolved.)

It seems to be related to typing into a text widget.  In xterm it dies,
and in xfig it dies when typing into the change-object menu text widgets.
Again, Vaxstation II Xqvss, gcc1.36, Ultrix 3.0, X11R4-PL12.
It works fine on a 4/280 under SunOs 4.1 with cc and, as several other
people have noted, on other suns.  

Please help. I will have to back out patch 12 until it is determined
what the problem is.
Thanks for any help.

Here again is the procedure where the death occurs (bus error):

_XtMatchUsingDontCareMods(0xbfaa0, 0x7fffd820) at 0x3f6b0
MatchEvent(0xbd4c4, 0x7fffd820) at 0x3f900
_XtTranslateEvent(0xbb604, 0xbb634, 0x7fffdcbc, 0x7fffd884) at 0x3fb1d
DispatchEvent(0x7fffdcbc, 0xbb604, 0x1, 0x89508) at 0x2feb9
DecideToDispatch(0x7fffdcbc) at 0x30267
XtDispatchEvent(0x7fffdcbc) at 0x302d6
XtAppMainLoop(0x89404) at 0x30589
XtMainLoop() at 0x30565
main.main(0x0, 0x7fffddf4, 0x7fffddfc) at 0xd818

_____________________________________
Brian V. Smith    (bvsmith@lbl.gov)
Lawrence Berkeley Laboratory
I don't speak for LBL, these non-opinions are all mine.

kaleb@mars.jpl.nasa.gov (Kaleb Keithley) (06/30/90)

In article <9006282345.AA22953@expire.lcs.mit.edu> rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes:
>
>    For example, xterm would startup,
>    but the second you tried to type anything in the window, the process would
>    die and dump core.
>
>Hmm, I rebuilt the public patched Xt on both a DECstation 3100 (cc)
>and a VAXstation 3100 (gcc), and linked xterms with them, and both
>xterms seemd to work just fine.  Beats me.  Has anyone gotten fix-12 to
>work?  Is anyone else having problems?  (If others are, I'll probably
>withdraw it until something gets resolved.)

I had this problem with fix-12 also on our Sun 4s.  Then I went back and did:
make clean.
make depend.
make.
make install.
ldconfig.

and then it started working.

kaleb@thyme.jpl.nasa.gov            Jet Propeller Labs
Kaleb Keithley

"So that's what an invisible barrier looks like"

hosking@cs.umass.edu (Tony &) (06/30/90)

I had similar problems as described in previous postings with installing fix
12 but I think I know what's going on. After applying the patch, I did a make
(not a "make World"!!!), in each of the 3 versions of the X hierarchy we have
around (one for the DECstation 3100, one for the VAXstations, and one for a
Mac II). As it turns out, make on the VAXstation rebuilt the *entire* Xt
library, whereas make on the DS3100 and the Mac only selectively rebuilt files
in mit/lib/Xt. When I tried to get X going on the VAXstation I had no
problems, however the DS3100 and the Mac II exhibited the problems that were
described in earlier postings. So, all I did was to "make clean" in mit/lib/Xt
and do a top-level make (not "make World") for each of the DS3100 and Mac II
mit hierarchies, and everything turned out OK.

I guess there are some weird differences in make between VAXen and the
DECstations and Mac IIs.

Hope this helps.
--
	Tony Hosking					
	Dept. of Computer and Information Science	 _--_|\
	University of Massachusetts			/      \
	Amherst, MA 01003				\_.--._/    )
	(413) 545-0256; hosking@cs.umass.edu		      v    /

envbvs@epb2.lbl.gov (Brian V. Smith) (06/30/90)

In article <HOSKING.90Jun29140113@ibis.cs.umass.edu>,
hosking@cs.umass.edu (Tony &) writes:
|> I had similar problems as described in previous postings with installing fix
|> 12 but I think I know what's going on. After applying the patch, I
did a make
|> (not a "make World"!!!), in each of the 3 versions of the X hierarchy
we have
|> around (one for the DECstation 3100, one for the VAXstations, and one for a
|> Mac II). As it turns out, make on the VAXstation rebuilt the *entire* Xt
|> library, whereas make on the DS3100 and the Mac only selectively
rebuilt files
|> in mit/lib/Xt. When I tried to get X going on the VAXstation I had no
|> problems, however the DS3100 and the Mac II exhibited the problems that were
|> described in earlier postings. So, all I did was to "make clean" in
mit/lib/Xt
|> and do a top-level make (not "make World") for each of the DS3100 and Mac II
|> mit hierarchies, and everything turned out OK.
|> 
|> I guess there are some weird differences in make between VAXen and the
|> DECstations and Mac IIs.
|> 

Actually, on our Vaxstation (Ultrix 3.0) it did not make the entire Xt
library, just the files that changed - and that is where the problem
was for our case.  When I did a "make clean", as you did for your DS3100
then everything worked ok.

>>> So, the answer appears to be "do a make clean before rebuilding Xt".

_____________________________________
Brian V. Smith    (bvsmith@lbl.gov)
Lawrence Berkeley Laboratory
I don't speak for LBL, these non-opinions are all mine.

kaleb@mars.jpl.nasa.gov (Kaleb Keithley) (06/30/90)

In article I wrote:
-In article <9006282345.AA22953@expire.lcs.mit.edu> rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes:
->
-I had this problem with fix-12 also on our Sun 4s.  Then I went back and did:
-make clean.
-make depend.
-make.
-make install.
-ldconfig.
-

I should have mentioned that I did this in src/mit/lib/Xt.

kaleb@thyme.jpl.nasa.gov            Jet Propeller Labs
Kaleb Keithley

"So that's what an invisible barrier looks like"

mike@tekgen.BV.TEK.COM (Mike Ewan) (06/30/90)

I've installed and run with fix-12 on Sun3 SunOS4.0 with no
problems.  I did a make Everything to install the fix-12.
It's been running a couple of days.  I've also installed it
on a VAXstation II/GPX and it works there, but I haven't
tested it much.

Mike

john@acorn.co.uk (John Bowler) (07/02/90)

MIT public fix #12 changed InitialI.h; with the (sole) exception of
Functions.c every lib/Xt .c file includes IntrinsicI.h, which includes
InitialI.h.  Therefore everything (except for Functions.o) should be
rebuilt.  The change in InitialI.h made a substantial change to the
XtPerDisplay structure - so if you have a system which recompiled
without rebuilding everything (possibly because of an omitted or
defective make depend step in the distant past) you probably now have
a defective libXt.a...

John Bowler (jbowler@acorn.co.uk)

stumpf@tuminfo2.informatik.tu-muenchen.de (Markus Stumpf) (07/02/90)

In article <9006282345.AA22953@expire.lcs.mit.edu>, rws@EXPO.LCS.MIT.EDU
(Bob Scheifler) writes:
|> Hmm, I rebuilt the public patched Xt on both a DECstation 3100 (cc)
|> and a VAXstation 3100 (gcc), and linked xterms with them, and both
|> xterms seemd to work just fine.  Beats me.  Has anyone gotten fix-12 to
|> work?  Is anyone else having problems?  (If others are, I'll probably
|> withdraw it until something gets resolved.)

Built it on DECstation 3100 (cc) and mVaxII (gcc) without any problems!
Everything works fine!

	\Maex


+- Markus Stumpf                         Technische Universitaet Muenchen   -+
|                            Institut fuer Informatik, Rechnerbetriebsgruppe |
|  stumpf@informatik.tu-muenchen.de              Postfach 202420             |
+-   ...@{unido.uucp,relay.cs.net}        D-8000 Muenchen 2, West Germany   -+

morreale@bierstadt.scd.ucar.edu (Peter Morreale) (07/03/90)

|> In article <9006282345.AA22953@expire.lcs.mit.edu>, rws@EXPO.LCS.MIT.EDU
|> (Bob Scheifler) writes:
|> |> Hmm, I rebuilt the public patched Xt on both a DECstation 3100 (cc)
|> |> and a VAXstation 3100 (gcc), and linked xterms with them, and both
|> |> xterms seemd to work just fine.  Beats me.  Has anyone gotten fix-12 to
|> |> work?  Is anyone else having problems?  (If others are, I'll probably
|> |> withdraw it until something gets resolved.)
|> 

  I've built on Sun3's, Sun4's with OS 4.0.3 and 4.1.  All is fine.
  (including a brand new Sun4/490 running 4.1, the "World" built 
  without a hitch...)

-PWM
------------------------------------------------------------------
Peter W. Morreale                  email:  morreale@ncar.ucar.edu
Nat'l Center for Atmos Research    voice:  (303) 497-1293
Scientific Computing Division     
Consulting Office
------------------------------------------------------------------

peirce@gumby.cc.wmich.edu (Leonard Peirce) (07/04/90)

On an unrelated note, I had a small problem applying fix 12.  The patches
bombed on mit/lib/Xt/Varargs.c.  I put them in by hand with no problem.  But
I'm surprised that it failed; I kept up with all of the patches (or so I
thought).  Did anyone else have this problem?
--
Leonard Peirce                  Internet:  peirce@gumby.cc.wmich.edu
Western Michigan University                peirce@gw.wmich.edu
Academic Computer Center        UUCP:      ...!uunet!sharkey!wmichgw!peirce
Kalamazoo, MI  49008            Phone:     (616) 387-5469