The following command line fails with SEGV since rev. 10822 The problem can be reproduced on i7a host in debug and release builds. gs/debugobj/gs -dJOBSERVER -sDEVICE=psdcmyk -r72 -o /dev/null \ gs/Resource/Init/gs_cet.ps - <../258-01.ps Rev. 10822 just adds more entries to a data dictionary in PDF interpreter. This should not affect PS interpreter at all. This command line also fails with SEGV in rev. 10005 and earlier. Rev. 10006 changes the memory allocation and hides the problem. #0 0x0000000000517c60 in ialloc_validate_object #1 0x00000000005175ba in ialloc_validate_chunk #2 0x000000000051720f in ialloc_validate_memory #3 0x000000000051090c in gc_validate_spaces #4 0x0000000000510bf6 in gs_gc_reclaim #5 0x00000000005b77d3 in context_reclaim #6 0x00000000004c72d0 in gs_vmreclaim #7 0x00000000004c7043 in ireclaim #8 0x00000000004bfdab in interp_reclaim #9 0x00000000004c0275 in gs_call_interp #10 0x00000000004bfe41 in gs_interpret #11 0x00000000004b3aac in gs_main_interpret #12 0x00000000004b45e1 in gs_main_run_string_end #13 0x00000000004b449e in gs_main_run_string_with_length #14 0x00000000004b440b in gs_main_run_string #15 0x00000000004b735b in run_string #16 0x00000000004b5bcf in swproc #17 0x00000000004b5852 in gs_main_init_with_args #18 0x00000000004099cd in main The list of other devices that fail with this command line follows, but both SEGV's happen in different places. This suggests that the bug is specific to psdcmyk device. ap3250 /rangecheck in --showpage-- bj10v Floating point exception bj10vh infinite loop cdj970 SEGV cgm* /undefined in --get-- md50Eco infinite loop md50Mono infinite loop photoex infinite loop rinkj SEGV sj48 /rangecheck in --showpage-- spotcmyk /invalidfileaccess in --showpage-- st800 /rangecheck in --showpage--
I haven't double checked but based on the svn regression report the following files also generate a seg fault with the psdcmyk device: 246-01.ps 272-01.ps
Reproduced, and as expected, this is a 'compressed color list' issue. Probably the other devices that use compressed color list also fail (tiffsep, tiffsep1). Turning on -Z? shows the subtable that is still (somehow yet unknown) referenced, but that is "not in any chunk" (i.e. has been freed).
The psdcmyk seg fault was caused by the gdevdevn.c compressed_color_list logic not using 'stable_memory' so a restore would free objects pointed to by the sub_level_ptrs array entries. Both the 'init' and 'add' functions are changed to use stable memory as of rev. 10905 As far as the other pseudo-random problems reported by Alex with other devices, if these still occur then one or more new, more specific bugs can be opened.