Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002114Core InformTablespublic2019-11-09 17:282019-11-10 09:57
Reporterotistdog 
Assigned To 
PrioritynormalSeverityseriousReproducibilityalways
StatusnewResolutionopen 
Platformx86OSWindowsOS Version7
Product Version6M62 
Target VersionFixed in Version 
Summary0002114: Trying to look up a corresponding entry for a value not found in the table crashes interpreter
DescriptionAn attempt to say a text value corresponding to a numeric value in a table, when the table does not contain the specified numeric value, causes a run-time error followed by a crash of the interpreter.

This is observed for both Linux and Windows environments.
Minimal Source Text To Reproduce
"Table Bug"

Place is a room.

Table of Error Causes
num	txt
1	"cat"
2	"mouse"
3	"duck"

After jumping:
	say txt corresponding to a num of 4 in Table of Error Causes.

test me with "jump".
Additional InformationThe RTP produced is:

"*** Run-time problem P21: Attempt to look up a non-existent correspondence in the table 'Table of Error Causes'."

The interpreter's final output is:

"Glulxe fatal error: Memory access out of range (6C756C01)"


Note that this issue appears very to be similar (same error messages and crash behavior) to bug 0001390, which is noted as fixed in 2015.
TagsNo tags attached.
Effect(mild) Inform 6 reports errors for invalid code
Attached Files

- Relationships

-  Notes
(0004893)
zarf (developer)
2019-11-10 09:57

On error, TableLookUpCorr() calls RunTimeProblem() and returns its value. Since this is a top-level function, that's 1, which is taken ill by the caller expecting a meaningful text value.

Returning 0 would be safe in this situation, and I guess most situations, but it could still lead to further runtime errors depending on the table column type. To be absolutely safe you'd want to return the default value for the type.

Also take a look at TableRowCorr(), which similarly returns 1 on error. 0 might be better, although I haven't looked at how that would work in a typical use case.

- Issue History
Date Modified Username Field Change
2019-11-09 17:28 otistdog New Issue
2019-11-10 09:57 zarf Note Added: 0004893


Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker