Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!sun-barr!olivea!mintaka!bloom-beacon!dont-send-mail-to-path-lines
From: mouse@lightning.mcrcim.mcgill.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re:  Running dclock on OpenWindows causing SunOS crash
Message-ID: <9105160414.AA05670@lightning.McRCIM.McGill.EDU>
Date: 16 May 91 04:14:20 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 34

> Environment: Sun 4/260 running SunOS 4.1.1 and OpenWindows 2.0

> We have a *very* strange problem...one of our users runs "dclock" (I
> believe patchlevel 4, but I'm not positive), and that user's server
> crashes every day precisely at 1:00pm.  If the user kills dclock
> before that time, then the system doesn't crash.  I've checked, and
> there's no cron jobs or anything else running.

> If I look at the logs in /usr/adm/messages*, some of the days don't
> have any crash indications.  Those which do all look the same:
> 	BAD TRAP
> 	pid xxxx, `xnews': Data fault
> 	kernel read fault at addr=0x0, pme=0x70000000
> 	Bus Error Reg 80<INVALID>

This looks singularly like something we observe here.  We have two
SPARCserver 470s running 4.1 (not 4.1.1...yet) and my mterm will, about
one time in ten, produce a strikingly similar panic on startup.
(Always just at startup.  If it survives the first second after the
window comes up, it'll survive fine...until the next mterm starts up.)
Stack traces from adb -k seem to imply that the crash is occurring
somewhere deep inside the scheduler, which, coupled with Sun's choice
to release a binary-only system, isn't much help.

Once, some process running emacs (we have at least two executables
called emacs, though I suspect that in this case it was GNU emacs)
produced a similarly inexplicable crash.

I, too, would be most interested in any solutions or rumors thereof.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu