[gs-bugs] [Bug 692367] New: GS crashes when changing file/ resolution/ etc from GSView

[bugzilla-daemon at ghostscript.com]

http://bugs.ghostscript.com/show_bug.cgi?id=692367

           Summary: GS crashes when changing file/ resolution/ etc from
                    GSView
           Product: Ghostscript
           Version: master
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P4
         Component: General
        AssignedTo: support at artifex.com
        ReportedBy: sags5495 at hotmail.com
         QAContact: gs-bugs at ghostscript.com


Steps to reproduce:

  - Display a file in GSView. The Ghostscript version I used is current 
    master (4a1159926a8094f19bcacddf0503b5a06edd9184) but an older master 
    and ghostscript-9.03 (at 2711662696407b82c2d382ae85567a5bd67f2037) 
    were crashing too, for the same reason. The GSView version is 4.6.
  - Either change some parameter, for example the resolution in order 
    to zoom in, or drag another file on the GSView's window.
  - At this point GS crashes.

>From what I in found, the problem is not with GSView but with Ghostscript.
Both GSView and the command line GS executable call the GSAPI functions, 
but gswin32c.exe does a single gsapi_init_with_args() + gsapi_exit(), 
while GSView does multiple such cycles.

During a gsapi_exit() call, imain.c::gs_main_finit() does a ‘restore 
past the bottom’ in line #865 ‘code = alloc_restore_all(idmemory);’.
The problem here is that 3 tables get freed, but dangling pointers to 
them remain in gs_lib_ctx. These tables are gs_name_table, 
io_device_table, and font_dir. I do not know if the new member 
profiledir is in the same situation (for example if COMPILE_INITS = 0).

The crash happens during the next gsapi_init_with_args() because of 
the dangling io_device_table pointer.

- imain.c::gs_main_init1() line #198 calls obj_init() and 
  gs_iodev_init(), in this order.
- during obj_init(), gs_setdevice_no_erase() get called, via 
  gsdevice.c::gs_nulldevice() line #615.
- ‘if (libctx->io_device_table != NULL’, gs_setdevice_no_erase()
  goes on with the ICC stuff, which ends with a crash while trying to
  access the non-existent io_device_table.

I’ll attach my patch, which solves the crash by clearing the 3 pointers.

What I don’t know/ I’m not sure about:

- If the gs_lib_ctx->profiledir (and profiledir_len) may exhibit a 
  similar problem for COMPILE_INITS = 0.
- If the initialization order ‘obj_init() then gs_iodev_init()’ is OK, 
  or it should be reversed. Obviously, some initialization is skipped 
  for the initial null device; I have no idea if this initialization, 
  at that point, is important or not.

-- 
Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.