Number: 

Date: 22-Aug-84 09':17':53

Submitter: Dering.pasa 

Source: Dering.pasa (Schoen - SDR)

Subject: SPURIOUS STACK OVERFLOW CAUSE FATAL CRASHES

Assigned To: 

Attn: 

Status: Incomplete

In/By: 

Problem Type: Bug

Impact: Fatal

Difficulty: Very Hard

Frequency: Intermittent

Priority: Absolutely

System: Language Support

Subsystem: Stack and Interpreter

Machine: 1108

Disk: 

Lisp Version: CAROL

Source Files: 

Microcode Version: 

Memory Size: 

File Server: 

Server Software Version: 

Disposition: '
["Sannella.PA" "22-Aug-84 18':00':55" Status':(New->Open) Priority':(->Absolutely)]'
["masinter" "13-Sep-84 14':43':03" Source': Difficulty':(->Very% Hard)]'
["Sannella.PA" "14-Sep-84 09':13':38" Description':]'
[given lack of more to go on and possible relation to the FUNARG ARs, I marked this one Incomplete]'
["masinter" "14-Sep-84 15':08':24" Status':(Open->Incomplete) Frequency':(Everytime->Intermittent) Disposition': Description':]'
["Masinter.pa" "18-Sep-84 17':23':16" Attn':]

Description: Eric Schoen of SDR reports the following repdroducible fatal crash.   While running under a mouse process he gets a break  with the error  "Stack Overflow".  Eric believes the overflow is spurious, as there are only about 10 frames on the stack.  He ↑ out of the break and continues.  Several minutes later his system falls into raid.  When he teleraids , the current stack frame is \Freestackblock which is called  from \Extendstack. The EndOfStack field of \InterfacePage is equal to \LastStackAddr.   The crash is not recoverable.'
'
-----'
'
Date': 13 Sep 84 14':41 PDT'
From': masinter.pa'
Subject': AR#1927, SPURIOUS STACK OVERFLOW CAUSE FATAL CRASHES'
To': Dering.pasa, Schoen@sumex-aim'
cc': masinter, vanMelle, LispSupport'
'
Did we exchange mail on this one? There are no additional notes in the AR.'
'
I think the main problem is that stack overflows happen in such a way that the process which gets the stack overflow interrupt isn''t necessarily the one that caused the error. I think what we *can* do is somehow make stack overflow interrupts "harder", i.e., interrupt *all* processes somehow.'
'
It should be that you could HARDRESET ("stop" from MP code or Control-D from TeleRaid/Raid) and get your state back. I''ve left it a high priority AR, but I don''t know exactly what to do about it.'
'
eturn-Path': <SCHOEN@SUMEX-AIM.ARPA>'
Received': from SUMEX-AIM.ARPA by Xerox.ARPA ; 14 SEP 84 11':49':30 PDT'
Date': Fri, 14 Sep 84 10':57':19 PDT'
From': Eric Schoen <Schoen@SUMEX-AIM.ARPA>'
Subject': Re': AR#1927, SPURIOUS STACK OVERFLOW CAUSE FATAL CRASHES'
To': masinter.pa, Dering.pasa'
cc': vanMelle.pa, LispSupport.pa'
In-Reply-To': Message from "masinter.pa@XEROX.ARPA" of Thu 13 Sep 84 14':41':00-PDT'
'
I noted when I got these stack overflows that there were a few unreleased'
stack pointers (the result of my creating a few FUNARGS), but the '
stack frames these represent couldn''t have been all that large.'
'
Thanks for looking into the problem; it''s a nuisance, but not all that'
destructive at the moment.'
'
Eric'


Workaround: 

Test Case: 

Edit-By: Masinter.pa

Edit-Date: 18-Sep-84 17':23':16