Number: 226

Date: 21-Mar-84 14':10':28

Submitter: le.pasa

Source: Teknowledge

Subject: MP 9016 (notFreeTrap - Stack allocation error) under Load

Lisp Version: Fugue.5

Description: '
Date': Wed, 21 Mar 84 13':51 PST'
From': Raim.pasa'
Subject': Teknowledge bug'
To': LE'
cc': 1100Support, Raim'
'
Bill White at Teknowledge reports the following':'
'
System': Fugue.5'
Machine':  1108'
'
The question he asks is': "Why does TeleRaid break with Invalid Address?"  Here is the scenario':'
'
Bill was loading files, copying corresponding sources to {core}, and ended up in 9016.'
'
Hit UNDO and got Teleraid cursor'
'
Hit ↑B  '
'
Instead of break, fell into 9004.'
'
Hit UNDO and got Teleraid cursor'
'
Went to another 1108, loaded Teleraid'
'
Typed (TELERAID 201Q)'
'
Got Virtual Raid and @-prompt':'
'
Typed L'
'
Displayed 1':    and then went into break': "Invalid address"'
'
ERRORSET'
\EVAL'
...'
REMOTEMAP'
VMAPPAGE'
VGETBASEPTR0'
V\BACKTRACE'
VRAIDCOMMAND'
ERRORSET'
VRAID'
TELERAID'
'
-----'
'
Date': 21 Mar 84 15':41 PST'
From': vanMelle.pa'
Subject': Partial postmortem of Teknowledge MP 9016'
To': 1100Support.pasa, LispSupport'
cc': vanMelle.pa'
'
I talked Bill White thru some teleraiding.  They had gotten a 9016, from which they tried ↑B from the TeleRaid server, only to get a 9305.  The latter he remotely TeleRaided, from which it was apparent the stack was trashed.  The top frame extension was odd-aligned.'
'
We laboriously tried parsing the stack farther back and found it was deep in interpreted code, in \EVALFORM in \EVAL in PROG1.  The \EVALFORM (and \EVAL) were of a (LOADB00nn --), part of an advised LOAD.  Everything looked kosher up until the \EVALFORM.  The frame for \EVALFORM was the last intelligible thing before the odd-aligned frame, and itself was slightly garbaged': the first word of its BF was trashed with 35563, a plausible nearby stack address, 4 less than that of the misaligned FX.  The PC of the \EVALFORM indicated it was executing the APPLYFN opcode.'


Workaround: 

Test Case: 

Edit-By: Charnley.pa

Edit-Date:  7-Jun-84 17':46':56

Attn: Charnley.pa

Assigned To: 

In/By: 

Disposition:  [tl':  First, the AR is OS/Virtual Memory (not processes). That is because it has to do with Invalid Address, which is a property of the virtual memory system.  Second, I''m having a hard time distilling what the Action Request here is. What happened that you don''t want to happen? Well, the first AR was that, when loading, he hit a 9016; fix the system so that it doesn''t happen. That isn''t a great AR since we don''t know why. 3/22/84]'
 [mjs 3/31/84 added follow-on message below]'
[Date':  2 Apr 84 12':48 PST'
From': vanMelle.pa'
AR 226': change to Attn Charnley; Priority Hopefully]

System: Operating System

Subsystem: Virtual Memory

Machine: 1108

Disk: 

Microcode Version: 

Memory Size: 

File Server: 

Server Software Version: 

Difficulty: 

Frequency: Once

Impact: Moderate

Priority: Hopefully

Status: Closed

Problem Type: Bug

Source Files: