Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!pyramid!decwrl!sun!guy From: guy@sun.uucp (Guy Harris) Newsgroups: net.unix-wizards Subject: Re: segmentation violation Message-ID: <7173@sun.uucp> Date: Thu, 11-Sep-86 13:20:01 EDT Article-I.D.: sun.7173 Posted: Thu Sep 11 13:20:01 1986 Date-Received: Fri, 12-Sep-86 01:57:12 EDT References: <150@whuxm.UUCP> Distribution: net Organization: Sun Microsystems, Inc. Lines: 35 > 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@sun.com (or guy@sun.arpa)