Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 (Tek) 9/26/83; site azure.UUCP
Path: utzoo!watmath!clyde!burl!mgnetp!ihnp4!houxm!vax135!cornell!uw-beaver!tektronix!teklds!azure!stevesu
From: stevesu@azure.UUCP (Steve Summit)
Newsgroups: net.unix-wizards
Subject: Re: Make makes shell dump core....
Message-ID: <31@azure.UUCP>
Date: Thu, 13-Sep-84 01:17:58 EDT
Article-I.D.: azure.31
Posted: Thu Sep 13 01:17:58 1984
Date-Received: Wed, 12-Sep-84 03:16:09 EDT
References: <905@trwrba.UUCP>
Organization: Tektronix, Beaverton OR
Lines: 43

I don't know why make depend is making the shell dump core, but I
do know why dbx is showing "a maze of 4.2 signal routines called
(apparently due to some sort of memory problem from within the
shell)."  It might have something to do with the core dump, and
it's good to know about, anyway.

The Bourne shell does memory management by a "hit or miss"
method.  It catches some signal (probably SIGSEGV, although I
have this memory that it's signal 12) to detect when it tries to
use memory it doesn't have yet.  The signal catch routine does an
sbrk(), and it tries whatever memory access it was doing again.

The problem is that the shell knows how to catch signals too
well.  It has this general signal catcher routine that ALWAYS
checks to see if signals were being ignored before it catches
them (and if you don't know why, read "Unix Programming" in
Volume 2 right away, in particular section 6).  It calls this
internal routine to catch SIGSEGV, and if for some reason SIGSEGV
was already being ignored, the shell will loop forever trying to
do something that ought to work once enough SIGSEGV's get caught
to allocate enough memory to allow what it's trying to do to work.

You can demonstrate this by writing a little C program that
ignores SIGSEGV and then exec's a shell that does any nontrivial
task.  The times I tried it the shell sat there in a loop doing
nothing but eating up all of the cpu it could get its hands on.

I suppose this could cause the core dump problem on the make
depend, somehow.  There may well be other problems.  The Bourne
shell is surprisingly strangely written for such a great program.
(By the way, I'm not trying to cut it down -- I use it in
preference to csh.)

A fix would be to put a check in the shell's internal catch
routine to catch SIGSEGV (or whatever the signal is) regardless. 
(By the way, I haven't gotten around to doing this yet, so don't
blame me if it doesn't work or if it breaks something else.)  One
thing that complicates the task is that the shell sources don't
#include signal.h (perhaps it was written before there was one).
Instead, it has all its own definitions for the signals.

                                         Steve Summit
                                         tektronix!tekmdp!stevesu