Using ‘File’/ ‘Convert...’ in GSView produces a crash in Ghostscript. To reproduce the crash with Ghostscript alone, execute: set GS_OPTIONS=@optionsfile gswin32c Cause: - Revision 11045 changed io_device_table from a global in base\gsiodev.c to a member of the gs_lib_ctx_t structure. - Both before and after the change, io_device_table gets its final value in base\gsiodev.c::gs_iodev_init(). - Until the gs_iodev_init() call, the old io_device_table, as all global variables, was set to NULL being initialized automatically. The new io_device_table is not initialized. - If the first argument processed is an @file, then io_device_table is used before calling base\gsiodev.c::gs_iodev_init(), via base\gsargs.c::arg_next() .. psi\zfile.c::lib_file_open() .. base\gsiodev.c::gs_getiodevice(). - psi\zfile.c::lib_file_open() contains a comment showing this situation is expected (‘/* when starting arg files (@ files) iodev_default is not yet set */’), and handles it gracefully. - However, now base\gsiodev.c::gs_getiodevice() finds some random non-NULL value in libctx->io_device_table, and crashes when dereferencing the pointer.
Created attachment 6164 [details] Suggested patch. Fix: 2 ex-global variables were not initialized immediately after being allocated. Bug 691249. Not initializing io_device_table to NULL produces a crash if the 1st argument processed is an ‘@file’. This happens for example when Ghostscript is called by GSWiev’s ‘File’/ ‘Convert...’ function, or when GS_OPTIONS starts with an ‘@file’ argument. While I do not know of (and neither looked for) any adverse effect of not initializing gs_name_table early, the patch does initialize this variable too. I consider this to be good practice, as it makes the code more robust.
appears to be caused by global variable removal
Many thanks. Your fix looks spot on. I'm actually testing a fix now that memsets the libctx to zero on initialisation. This should be even safer than your fix as it saves us from me forgetting to initialise other newly added members in future.
This was fixed 2 months 3 weeks ago in revision 11218, and I forgot to close the bug. Closing now.