| Summary: | Misleading error message from 'runlibfile0' | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | SaGS <sags5495> |
| Component: | General | Assignee: | Alex Cherepanov <alex> |
| Status: | NOTIFIED FIXED | ||
| Severity: | normal | ||
| Priority: | P4 | ||
| Version: | 8.56 | ||
| Hardware: | PC | ||
| OS: | All | ||
| Customer: | Word Size: | --- | |
| Attachments: |
Suggested patch.
Suggested patch. |
||
Created attachment 2258 [details]
Suggested patch.
Created attachment 2259 [details] Suggested patch. (Please ignore attachment #2258 [details], I picked up the wrong file.) preliminary analysis says the patch is acceptable; Ray will do some testing with job server and compile inits. Need to test with regression suite and with COMPILE_INITS=1 The patch is committed as a rev. 8054. There's no differences in either state of COMPILE_INITS flag. |
DESCRIPTION --- If an error occurs, "lib\gs_init.ps::runlibfile0", which replaces the regular "runlibfile" during the initialization, is intended to print the failing file name ("While reading <filename>:"). However, it does not handle NESTED "runlibfile" calls, and in such a case the error message does not correctly point to the failing file. The error consists in not restoring ".currentfilename" when the (nested) libfile ends, so the error message always refers to the last libfile that was ever STARTED, even if this finished and control returned to another file. Example, for SVN rev 6840: - Windows platform, GS_LIB includes "\"s as path separators - "lib\gs_init.ps" uses "runlibfile" to run, among others, "lib\gs_fntem.ps" - "runlibfile0" sets ".currentfilename" to "(gs_fntem.ps)" then start executing this file; - "lib\gs_fntem.ps" uses (nested) calls to "runlibfile" either directly (for example to run "lib\xlatmap"), or indirectly (via the stubs from "lib\gs_init.ps::EncodingDirectory") invoking "StandardEncoding", ..., "DingbatsEncoding" - during the "DingbatsEncoding" call, "runlibfile0" sets ".currentfilename" to "(gs_dbt_e.ps)" - "lib\gs_dbt_e.ps" finishes OK, but upon return "runlibfile0" does NOT restore ".currentfilename" to "(gs_fntem.ps)" - a few lines later (line "cvn dup /Encoding findresource"), "lib\gs_fntem.ps" fails (unrelated bug 688737 "'resourceforall' truncates names of file-based resources") - the initial "runlibfile" intercepts the error, but the filename printed as part of the error message is incorrect: "While reading gs_dbt_e.ps:" instead of "... gs_fntem.ps:". SUGGESTED FIX --- The attached patch changes "lib\gs_init.ps::runlibfile0" to define ".currentfilename" again after the libfile ends. The correct value is kept on the exec stack, by constructing and executing a procedure with the filename bound into it.