Trailing-Edge
-
PDP-10 Archives
-
bb-bt99g-bb
-
alg10b.d12
There is 1 other file named alg10b.d12 in the archive. Click here to see a list.
EDIT DESCRIPTIONS FOR ALGOL-10-V10B
EDIT 362 FOR ALGOL
[SYMPTOM]
INPUT and OUTPUT procedures accept null device names.
[DIAGNOSIS]
Null device names are not legal. ALGLIB knows this, but expects the
ALGOTS routine to detect it by getting an error from the DEVCHR UUO.
However, when ALGOTS passes the null name to DEVCHR, DEVCHR thinks it
is a channel number (channel 0). If a device has already been
assigned to channel 0, the DEVCHR returns the characteristics for that
device and no error occurs.
[CURE]
In ALGLIB procedure INPUT/OUTPUT, check for a null name. If one is
found, produce a fatal error.
********************************************************************************
EDIT 363 FOR ALGOL
[SYMPTOM]
Incorrect PC and line number reported on a runtime error
message, dealing with mismatched formal and actual
parameters in a procedure call. Occasional illegal memory
references when trying to DUMP variables afterward.
[DIAGNOSIS]
Incorrect PC/line number:
The code introduced at ERRM2: by edit 242 is correct if and
only if the error being reported is "incorrect number of
parameters." For any other error, the wrong PC (and hence
the wrong line number) would be reported. The "incorrect
number of parameters" error had been generating an incorrect
line number, but edit 242 erroneously fixed the error
reporting code rather than the error detecting code.
Ill mem ref:
The error reporting code in ALGOTS (ERRMNX et al) and ALGDDT
(HSTPRT) assumes (not unreasonably) that the display pointed
to by DL is properly set up. If the error occurs during
parameter evaluation (PARAM, PAR0), however, this is not
necessarily true. Since the display contains information on
how to access variables, if it isn't completely set up then
DUMP will either report garbage or ill mem ref. PARAM must
insure that a sufficiently good DL and %DDTDL are available
to the error reporting code and ALGDDT whenever an error may
be reported. Edit 202 tried to do something about this, but
wound up confusing things instead.
Finally, HSTPRT was prematurely saving DL, before it had
determined that DL was in fact the correct context. This
contributed to the ill mem ref problem.
Although these two problems seem to be distinct, they are in
fact related by the environment in which the error is
reported. In both cases the problem may be traced (directly
or indirectly) to an inconsistent or incomplete display.
This is primarily the fault of PARAM, which is entirely too
eager to report errors.
[CURE]
The patch has the following effects:
o PARAM now waits until the overhead portion of the
new DL is established before trying to detect
errors. In particular, PRGLNK(DL) must be set up
before error reporting will work properly.
o PARAM now puts off setting up a new %DDTDL until
all parameters have been evaluated. %DDTDL must
point to a complete context, and DL does not until
after all parameters are evaluated.
Page 2
o Replaces edit 242 with code which looks in
PRGLNK(DL) for the address of the subroutine call.
With the changes to PARAM, this should always be
set up.
o Removes edit 202.
o Keeps HSTPRT from setting up %DDTPC prematurely.
This had been allowing context to be established at
an incomplete display level.
With this patch installed, an error during parameter
evaluation will have the new procedure's DL set up, although
incomplete, for proper error location reporting; and will
have the old display addressed by %DDTDL, where ALGDDT will
find a complete display for use in debugging safely.
********************************************************************************
EDIT 364 FOR ALGOL
[SYMPTOM]
After an "EXPRESSION TOO LONG" error the Algol compiler may
spuriously fail in any of a number of ways, including: ill
mem ref; infinite loop; UNDEFINED LABEL messages with
garbage labels.
[DIAGNOSIS]
Algol detects "EXPRESSION TOO LONG" by reaching the end of
tempcode (comparing INDEX to TCMAX). That may not be the
last time INDEX is incremented, however. If INDEX increases
past TCMAX, part of the symbol table as well as STBB may end
up trashed.
[CURE]
Whenever tempcode overflows, reset it to empty.
********************************************************************************
EDIT 365 FOR ALGOL
[SYMPTOM]
Ill mem refs or heap consistency errors after edit 356 has
been installed (autopatch tape 9). Parts of the heap and
the program may be written over with garbage. Heap free
list (%SYS2(DB)) is junk.
[DIAGNOSIS]
Edit 356 incorrectly added an entry, %SYS18, into the middle
of the runtime database. Since the compiler sometimes
generates code which accesses the database, this could cause
programs compiled previously to sometimes access the wrong
entry in the database; in particular, instead of
decrementing the dynamic procedure level, some programs will
decrement the pointer into the trace window. Since the
trace window is the first item on the heap, when it wraps
around (with the wrong pointer) it will start writing over
the heap free list, with devastating results. The heap
consistency checker will detect this, if it is turned on
(FTGETCHK=1 in ALGOTS).
[CURE]
Install edit 356 if not already installed. Then install
edit 365. This moves %SYS18 to the end of the database.
Once the patch is installed, rebuild both the OTS and
compiler. Then recompile any programs compiled while edit
356 alone was in effect.
********************************************************************************
EDIT 366 FOR ALGOL
[SYMPTOM]
Overlaid programs run out of memory after switching back and
forth between overlay branches several times.
[DIAGNOSIS]
When OVRLAY brings in a new overlay branch, it calls FUNCT.
with the "Cut Back Core" function in an attempt to keep the
low seg as small as possible. ALGOTS has no real mechanism
for actually shrinking the low seg; instead, ALGOTS's
response to the "Cut Back Core" function of FUNCT. is to
move the overlay free list in with the normal free list.
This can have an unwanted side effect of increasing
fragmentation (instead of reducing it) since subsequent
requests for normal heap may be fulfilled from the memory
that OVRLAY wants. OVRLAY's attempts to free the space
(e.g. by moving the symbol table) obviously won't work, and
eventually the program runs out of room.
[CURE]
Make FNCCBC (the "Cut Back Core" function of FUNCT.) into a
no-op. This causes the two heaps (overlay and normal) to be
eternally separate, but won't actually increase
fragmentation noticeably (since OVRLAY usually wants memory
in specific places where the normal heap wouldn't go
anyway). Also modify the heap integrity checker to deal
with the FUNCT. free list as well as the normal free list.
Note that fragmentation may still increase slightly as a
result of this patch; any memory allocated to FUNCT. with
FNCCOR (core anywhere) from the normal heap will be returned
to the overlay free list, not the normal free list. This is
a rare event, however, so is a far less significant problem.
Edits 326 and 361 must be installed first.
********************************************************************************
END OF ALGOL-10-V10B