|Anonymous | Login | Signup for a new account||2020-07-07 12:42 PDT|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002114||Core Inform||Tables||public||2019-11-09 17:28||2019-11-10 09:57|
|Target Version||Fixed in Version|
|Summary||0002114: Trying to look up a corresponding entry for a value not found in the table crashes interpreter|
|Description||An 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 Information||The 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.
|Tags||No tags attached.|
|Effect||(mild) Inform 6 reports errors for invalid code|
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.
|2019-11-09 17:28||otistdog||New Issue|
|2019-11-10 09:57||zarf||Note Added: 0004893|
|Copyright © 2000 - 2010 MantisBT Group|