Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Lawrence Statton NK1G <lawrence@senguio.mx>
Newsgroups: alt.folklore.computers,comp.sys.raspberry-pi
Subject: Re: S/360 stacks, was self-modifying code, Is it a lost cause?
Date: Tue, 05 Jul 2016 13:24:51 -0500
Organization: A noiseless patient Spider
Lines: 33
Message-ID: <87d1ms0wp8.fsf@senguio.mx>
References: <njmu8u$3i6$1@dont-email.me> <nlef15$l8c$1@dont-email.me> <1107158795.489361340.954697.peter_flass-yahoo.com@news.eternal-september.org> <nlf0ho$npt$1@dont-email.me> <nlf722$1gom$1@miucha.iecc.com> <nlfpb7$58u$1@news.albasani.net> <nlgldo$tkd$1@dont-email.me> <slrnnnnmno.754.nomail@xs9.xs4all.nl> <nlgstu$qv5$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: mx02.eternal-september.org; posting-host="145d6435d2d8ad643675fb18ce63a8a8"; logging-data="32732"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/Nb9mff/LYtMtvKQlvxpRo"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
Cancel-Lock: sha1:dYbkyzXpBxDYn1qVMN1bZqM+QIo= sha1:3/eIm/VfMK8CdBTXJARqc7V0AIo=
Xref: csiph.com alt.folklore.computers:166692 comp.sys.raspberry-pi:12540

Dan Espen <despen@verizon.net> writes:
>> This is implementation (mostly OS) dependant.  Usually there is a
>> signal for stack overflow, but it often is the generic signal for
>> invalid memory accessed (SIGSEGV in Unix/Linux).
>
> Which leaves you no way to programmaticly detect the overflow.
> The end user could add memory to the job if he got an informative
> message.

While I've never done it, it should be a SMOP to trap the SEGV
exception, and write a handler (using a private area of memory set aside
for its own stack) to at least report the problem.  That'd be some
tricky 'battling with the compiler' to get the execution environment set
up, but no more than a day of hair extraction.

> It's somewhat ironic, you put all that coding in for malloc failure
> and end up being unable to detect stack allocation failure.

Hysterical Raisins, I think ... At some reference point in history,
stack overflow just "never happened" and running out of arena happened
all the time.  

A "stack heavy" algorithm like walking a balanced tree only uses
O(log2(N)) levels of stack -- I can walk a billion element tree using 31
stack frames.

Twenty years ago, I had cause to instrument a moderately complex system
in C, with much recursive code, and the stack never grew to more than
1,100 bytes.  On a modern Unix-like system, the stack is given by
default 8 mibibytes.