Path: utzoo!attcan!uunet!philmtl!atha!decwrl!bacchus.pa.dec.com!shlump.nac.dec.com!tkou02.enet.dec.com!diamond
From: diamond@tkou02.enet.dec.com (diamond@tkovoa)
Newsgroups: comp.unix.ultrix
Subject: Re: emacs or csh problem?
Message-ID: <1876@tkou02.enet.dec.com>
Date: 27 Jul 90 02:40:17 GMT
References: <27522@netnews.upenn.edu>
Reply-To: diamond@tkou02.enet.dec.com (diamond@tkovoa)
Organization: Digital Equipment Corporation Japan , Tokyo
Lines: 36

In article <27522@netnews.upenn.edu> hagan@scotty.dccs.upenn.edu (John Dotts Hagan) writes:

>I have submitted a problem to Digital about trouble starting jobs from
>/bin/csh, specifically gnu emacs.  Unfortunately, Digital seems highly
>skeptical that I am really having a problem:
>   "I think I mentioned that we have hundreds of
>   people here using emacs and the reported seg fault problem has never been
>   seen here."

Well, the response was almost suitable.  The problem is not in emacs.
You say so yourself:

>The Segmentation fault occurs almost instantly, and core rarely dumps.  The
>few times core has dumped, it is always a core dump of /bin/csh, not emacs.
>Since the dumps are of the csh, and it fault happens so fast, I believe the
>csh is having trouble starting the emacs task, rather than emacs causing the
>problem.
>...  The expire program that failed to start
>was in a /bin/csh script started bu cron, and all of these other scripts that
>failed are /bin/csh scripts.

I had similar problems on a MIPS box at a previous employer.  The failures
were often in csh but also often in other programs such as the ld step of
a cc command.  I haven't seen it on a DECstation (yet) but it looks like
this narrows it down to code that was inherited from MIPS.  Sometimes I had
the same problem while debugging a program that I wrote myself:  If the
program aborted, and I tried running it under dbx, it would get a segmentation
fault as soon as I said "run" -- repeatedly.  Perhaps certain environments
set up segments of some particular lengths, or by some other unknown means
they manifest an intermittent bug in address mapping/paging/swapping/
who knows.  Or perhaps the kernel forgets to delete a signal that has been
delivered, so it gets delivered again when a new process bears a certain
characteristic.  I hope these guesses might help locate the problem.
-- 
Norman Diamond, Nihon DEC     diamond@tkou02.enet.dec.com
This is me speaking.  If you want to hear the company speak, you need DECtalk.