segmentation violation

[Guy Harris]

> On our 3B20 (although the problem is probably generic),

It is; a machine can run out of address space to support the stack, if
nothing else.

> I can try to do a setjmp() at the beginning of the series of calls that 
> cause the problem and then try to do a longjmp() in the catching routine, 
> but I really need to hold my breath and hope that there is enough room 
> for this (small) catching routine to execute. (long sentence, eh?)

There probably won't be.  The very act of delivering the signal causes some
stuff to be pushed onto the stack on most machines, usually stuff similar to
what traps push onto the (kernel) stack (and I suspect the 3B20 is no
exception).

> Any other suggestions (besides "use a machine with demand
> paging/virtual memory") ?

Well, the right versions of S5R2 for the 3B20 *do* support demand paging,
but they still impose *some* limit on the maximum size of the stack.

Of course, there are other versions of UNIX that not only support demand
paging, but permit you to catch this signal on a "signal stack" and, if you
can, fix it; you might check with the University of Texas(?) to see whether
they're working on the 4.2BSD port to the 3B20 that I'd heard it claimed
they were working on... (another reason why the 4.1BSD signal mechanism that
was dropped into S5R3 Just Isn't Good Enough).

Actually, you should also check whether they've switched to 4.3BSD; the
4.2BSD mechanism Isn't Quite Good Enough either, as it pushes the "signal
context" structure onto the regular stack, rather than the signal stack....
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy at sun.com (or guy at sun.arpa)