Created attachment 7704 [details] PDF crashing gs 9.00. gs 9.00, openSUSE 11.4 PDF created by firefox 5. This PDF works fine in gs 8.62 (openSUSE 11.1), xpdf, okular, acroread 9.4.2. Error: /rangecheck in --.discardtransparencygroup-- Operand stack: --dict:7/16(L)-- Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1910 1 3 %oparray_pop 1909 1 3 %oparray_pop 1893 1 3 %oparray_pop 1787 1 3 %oparray_pop --nostringval-- %erroreGPL Ghostscript 9.00: Unrecoverable error, exit code 1 xec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push --nostringval-- --nostringval-- Dictionary stack: --dict:1176/3371(ro)(G)-- --dict:1/20(G)-- --dict:82/200(L)-- --dict:108/127(ro)(G)-- --dict:293/300(ro)(G)-- --dict:23/30(L)-- --dict:6/8(L)-- --dict:21/40(L)-- --dict:5/5(L)-- Current allocation mode is local Last OS error: 11
Thank you for using and testing Ghostscript. The problem is confirmed in v.9.00, but it is fixed in v.9.01, v.9.02, and the current development version. Please upgrade.
Hi Alex, upgrading ghostscript on Linux systems is not so easily possible, because it is integrated into cups, and there at least used to be a large number of distribution-specific changes as well. Replacing all that with a vanilla ghostscript is likely to lead to trouble. More realistically it'll have to involve a complete system upgrade, assuming vendor is able to upgrade, but I'll put in a request to that effect. Meanwhile I'll put up with gs basically being unusable at least on the PDF side because of too many crashes (this report here isn't the only problem). Thanks for working on improvements!
Actaully, I _was_ able to reproduce this. Crash confirmed on Windows debug build of origin/master (68bf978) Fails with call stack: gsicc_new_iccsmask(gs_memory_s * memory=0x504c1010) Line 175 gsicc_initialize_iccsmask(gsicc_manager_s * icc_manager=0x01dce810) Line 194 gs_begin_transparency_mask(gs_state_s * pgs=0x01dbe050, const gs_transparency_mask_params_s * ptmp=0x000ce500, const gs_rect_s * pbbox=0x000ce4d8, int mask_is_image=0x00000001) Line 587 zbegintransparencymaskimage(gs_context_state_s * i_ctx_p=0x01dce970) Line 324 When the icc_manager has a 'memory' pointer that is NULL (0x00000000) Interestingly, the profiles that are initialized (such as default_gray) have valid 'memory' pointers. Assigning to Michael Vrhel, but someone else might be able to track this down since it is so easily reproduced.
I started tracing this and discovered that even though my 'nmake' (VS Build Solution) was coming back as current, the structure was out of sync and the setting of result->srcgtag_profile = NULL was actually setting the 'memory' element of the structure. It may be that we have a dependency problem, but a Rebuild (clean, then build) made the problem go away. Returning this to 'FIXED' status. Sorry for the false alarm.