The attached pdf file from the customer causes Ghostscript CVS HEAD to segfault. Tried with both the png16m and the pcxcmyk device. NOTE: This customer's status is currently non-supported. I've recorded their number for tracking, but this shouldn't influence its priority.
Created attachment 930 [details] IndesigngradientCMYK-small.pdf
On PC I've got the following for any resolution above 72 dpi. gswin32c -dNOPAUSE -dBATCH -r73 -sDEVICE=pcxcmyk -sOutputFile=a.pcx file.pdf Processing pages 1 through 1. Page 1 *** C stack overflow. Quiting...
Can't reproduce with the current HEAD with MSVC6 neither with debug, nor with release build. Please provide more information about the compiler and the revision.
I'm using -GZ for the debug build.
Still can't reproduce. Please provide the following info : 1. Compiler version, compiler service pack version; 2. Ghostscript checkout time (for example "09/16/2004 10:00:00 PDT"). If you don't know exactly, please check it out again with a known time. 3. Additional options building Ghostcript, if any; 4. A command line; 5. A font set - URW, SoftHorizon, or else. Also please run C debugger, with Debug/Exceptions check on the stack overflow exception 0xC00000FD with "Stop always", and run GS in the debug session. Give me the stack snap at the exception point. Rather the stack may be too long, you'll know the function name, and variable values in there. I suspect that your effect is caused by shadings, and I am interesed in fixing it.
I can reproduce this on NT SP6, but cannot on XP with all other parameters being the same. Re your questions: 1. Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86 2. Current CVS, 2004-10-6 3:07 PST 3. nmake -f .\src\msvc32.mak AROOTDIR=s:/gs_root DEBUG=1 DEVSTUDIO=c:\visual~1 MSVC_VERSION=6 CFLAGS=-GZ WARNOPT=-W3 debug 4. gswin32c -dNOPAUSE -dBATCH -r73 -sDEVICE=pcxcmyk -sOutputFile=a.pcx file.pdf 5. gs-fonts v. 8.11 (base 35, GPL) ESP == 0x3ff84 in main() ESP == 0x33000 in gs_debug_c() The stack trace: gs_debug_c(int 104) line 109 set_color_ht_le_4(unsigned char * 0x0003368c, unsigned int 4, int 280, int 2026, int 1, int 1, int 4, int 0, int 4, unsigned __int64 7, gx_device_s * 0x0003dff4, const color_values_pair_s * 0x000335f0, unsigned __int64 * 0x000334f0, const gx_const_strip_bitmap_s * * 0x000334b0) line 1176 + 7 bytes gx_dc_ht_colored_fill_rectangle(const gx_device_color_s * 0x00033f68, int 280, int 2026, int 1, int 1, gx_device_s * 0x0003dff4, unsigned int 252, const gx_rop_source_s * 0x00000000) line 738 + 121 bytes gx_fill_trapezoid_ns_nd(gx_device_s * 0x0003dff4, const gs_fixed_edge_s * 0x00033d6c, const gs_fixed_edge_s * 0x00033d5c, long 518755, long 518814, int 0, const gx_device_color_s * 0x00033f68, unsigned int 252) line 377 + 44 bytes gx_default_fill_trapezoid(gx_device_s * 0x0003dff4, const gs_fixed_edge_s * 0x00033d6c, const gs_fixed_edge_s * 0x00033d5c, long 518755, long 518814, int 0, const gx_device_color_s * 0x00033f68, unsigned int 252) line 431 + 35 bytes gx_shade_trapezoid(patch_fill_state_s * 0x0003a75c, const gs_fixed_point_s * 0x00034088, int 0, int 1, int 3, int 2, long 518755, long 518814, int 0, const gx_device_color_s * 0x00033f68, int 0) line 1235 + 54 bytes constant_color_quadrangle(patch_fill_state_s * 0x0003a75c, const quadrangle_patch * 0x000345a0, int 0) line 2477 + 47 bytes fill_quadrangle(patch_fill_state_s * 0x0003a75c, const quadrangle_patch * 0x000345a0, int 0) line 3118 + 64 bytes fill_quadrangle(patch_fill_state_s * 0x0003a75c, const quadrangle_patch * 0x0003480c, int 0) line 3222 + 17 bytes fill_quadrangle(patch_fill_state_s * 0x0003a75c, const quadrangle_patch * 0x00034a98, int 0) line 3230 + 17 bytes fill_quadrangle(patch_fill_state_s * 0x0003a75c, const quadrangle_patch * 0x00034d44, int 0) line 3230 + 17 bytes fill_quadrangle(patch_fill_state_s * 0x0003a75c, const quadrangle_patch * 0x00034f48, int 1) line 3222 + 17 bytes decompose_stripe(patch_fill_state_s * 0x0003a75c, const tensor_patch * 0x00035684, int 1) line 3311 + 18 bytes decompose_stripe(patch_fill_state_s * 0x0003a75c, const tensor_patch * 0x00035bec, int 2) line 3296 + 25 bytes decompose_stripe(patch_fill_state_s * 0x0003a75c, const tensor_patch * 0x00036154, int 4) line 3296 + 25 bytes decompose_stripe(patch_fill_state_s * 0x0003a75c, const tensor_patch * 0x000366bc, int 8) line 3296 + 25 bytes decompose_stripe(patch_fill_state_s * 0x0003a75c, const tensor_patch * 0x00036c24, int 16) line 3296 + 25 bytes decompose_stripe(patch_fill_state_s * 0x0003a75c, const tensor_patch * 0x0003766c, int 32) line 3296 + 25 bytes fill_stripe(patch_fill_state_s * 0x0003a75c, const tensor_patch * 0x0003766c) line 3358 + 17 bytes fill_patch(patch_fill_state_s * 0x0003a75c, const tensor_patch * 0x0003766c, int 0, int 0, int 0) line 3501 + 13 bytes fill_patch(patch_fill_state_s * 0x0003a75c, const tensor_patch * 0x0003798c, int 0, int 0, int 0) line 3550 + 43 bytes fill_patch(patch_fill_state_s * 0x0003a75c, const tensor_patch * 0x00037e5c, int 0, int 0, int 0) line 3553 + 43 bytes fill_patch(patch_fill_state_s * 0x0003a75c, const tensor_patch * 0x000384dc, int 0, int 0, int 0) line 3553 + 43 bytes fill_patch(patch_fill_state_s * 0x0003a75c, const tensor_patch * 0x000389ac, int 0, int 0, int 0) line 3550 + 43 bytes fill_patch(patch_fill_state_s * 0x0003a75c, const tensor_patch * 0x00038e7c, int 0, int 0, int 0) line 3550 + 43 bytes fill_patch(patch_fill_state_s * 0x0003a75c, const tensor_patch * 0x0003934c, int 0, int 0, int 0) line 3550 + 43 bytes fill_patch(patch_fill_state_s * 0x0003a75c, const tensor_patch * 0x0003981c, int 0, int 0, int 0) line 3550 + 43 bytes fill_patch(patch_fill_state_s * 0x0003a75c, const tensor_patch * 0x00039cec, int 1, int 1, int 1) line 3550 + 43 bytes fill_patch(patch_fill_state_s * 0x0003a75c, const tensor_patch * 0x00039f58, int 2, int 2, int 2) line 3550 + 43 bytes patch_fill(patch_fill_state_s * 0x0003a75c, const patch_curve_s * 0x0003a180, const gs_fixed_point_s * 0x00000000, void (gs_fixed_point_s *, const patch_curve_s *, const gs_fixed_point_s *, double, double)* 0x00000000) line 3736 + 37 bytes R_tensor_annulus(patch_fill_state_s * 0x0003a75c, const gs_rect_s * 0x0003e2dc, double 0.00000000000000, double 0.00000000000000, double 0.00000000000000, double 0.00000000000000, double 0.00000000000000, double 0.00000000000000, double 1.0000000000000, double 1.0000000000000) line 1001 + 20 bytes gs_shading_R_fill_rectangle_aux(const gs_shading_s * 0x00b28348, const gs_rect_s * 0x0003e2dc, gx_device_s * 0x0003dff4, gs_imager_state_s * 0x00b0c8e0) line 1458 + 116 bytes gs_shading_R_fill_rectangle(const gs_shading_s * 0x00b28348, const gs_rect_s * 0x0003e2dc, gx_device_s * 0x0003dff4, gs_imager_state_s * 0x00b0c8e0) line 1615 + 21 bytes gs_shading_fill_path(const gs_shading_s * 0x00b28348, gx_path_s * 0x0003e464, const gs_fixed_rect_s * 0x00000000, gx_device_s * 0x00a100a8, gs_imager_state_s * 0x00b0c8e0, int 0) line 564 + 22 bytes gs_shading_fill_path_adjusted(const gs_shading_s * 0x00b28348, gx_path_s * 0x0003e464, const gs_fixed_rect_s * 0x00000000, gx_device_s * 0x00a100a8, gs_imager_state_s * 0x00b0c8e0, int 0) line 577 + 29 bytes gx_dc_pattern2_fill_path(const gx_device_color_s * 0x0003e67c, gx_path_s * 0x0003e464, gs_fixed_rect_s * 0x00000000, gx_device_s * 0x00a100a8) line 220 + 44 bytes gx_default_fill_path(gx_device_s * 0x00a100a8, const gs_imager_state_s * 0x009d8f40, gx_path_s * 0x0003e854, const gx_fill_params_s * 0x0003e5ec, const gx_device_color_s * 0x0003e67c, const gx_clip_path_s * 0x00b04e70) line 562 + 22 bytes gx_fill_path(gx_path_s * 0x0003e854, gx_device_color_s * 0x0003e67c, gs_state_s * 0x009d8f40, int -1, long 0, long 0) line 53 + 33 bytes gs_shfill(gs_state_s * 0x009d8f40, const gs_shading_s * 0x00b28348) line 89 + 26 bytes zshfill(gs_context_state_s * 0x009e9680) line 80 + 21 bytes call_operator(int (gs_context_state_s *)* 0x10145590 zshfill(gs_context_state_s *), gs_context_state_s * 0x009e9680) line 107 + 7 bytes interp(gs_context_state_s * * 0x008c057c, const ref_s * 0x0003f10c, ref_s * 0x0003f2c8) line 1492 + 39 bytes gs_call_interp(gs_context_state_s * * 0x008c057c, ref_s * 0x0003f10c, int 1, int * 0x0003f2d0, ref_s * 0x0003f2c8) line 488 + 17 bytes gs_interpret(gs_context_state_s * * 0x008c057c, ref_s * 0x0003f10c, int 1, int * 0x0003f2d0, ref_s * 0x0003f2c8) line 447 + 25 bytes gs_main_interpret(gs_main_instance_s * 0x008c03a8, ref_s * 0x0003f180, int 1, int * 0x0003f2d0, ref_s * 0x0003f2c8) line 302 + 31 bytes gs_main_run_string_end(gs_main_instance_s * 0x008c03a8, int 1, int * 0x0003f2d0, ref_s * 0x0003f2c8) line 610 + 25 bytes gs_main_run_string_with_length(gs_main_instance_s * 0x008c03a8, const char * 0x008c3038, unsigned int 26, int 1, int * 0x0003f2d0, ref_s * 0x0003f2c8) line 568 + 21 bytes gs_main_run_string(gs_main_instance_s * 0x008c03a8, const char * 0x008c3038, int 1, int * 0x0003f2d0, ref_s * 0x0003f2c8) line 551 + 38 bytes run_string(gs_main_instance_s * 0x008c03a8, const char * 0x008c3038, int 3) line 775 + 28 bytes runarg(gs_main_instance_s * 0x008c03a8, const char * 0x1053f074 `string', const char * 0x008c25c8, const char * 0x1054f360 `string', int 3) line 765 + 17 bytes argproc(gs_main_instance_s * 0x008c03a8, const char * 0x007a0f4e) line 700 + 25 bytes gs_main_init_with_args(gs_main_instance_s * 0x008c03a8, int 9, char * * 0x007a0750) line 214 + 13 bytes gsapi_init_with_args(void * 0x008c0718, int 9, char * * 0x007a0750) line 169 + 28 bytes main(int 7, char * * 0x007a0ed0) line 421 + 20 bytes GSWIN32C! mainCRTStartup + 197 bytes KERNEL32! 77f1b9ea()
Alex, Thank you for the info supplied. My compiler version is 12.00.8804 for 80x86. Likely your one, or linker, or NT either allocates a smaller C stack, or bigger stack frames. Please check the data alignment option when you run compiler (IMO it should be 1byte). In any case, your stack snap doesn't look wrong - no infinite recursion in there (actually it finished 2 recursions), just insufficient space for few more stack frames. I consider up to 64 levels of decomposition (fill_patch, decompose_stripe, fill_quadrangle) is normal and must fit into the stack size, which by default is 64K. Please measure the stack size and stack frame sizes in your environment. I'd like to assign this bug to you because I have no environment for it. If you agree, please change the assignment.
Also please check the default value for /Gs option with your compiler version. I recall in the past they had problems with it.
This customer is now supported, and this should be considered a normal customer bug with corresponding priority.
Igor, I don't know what to do about this bug. Small increase of the stack size in *.def files helps. None of -Zp1 -Gs0 -Gs1 -Ge helps. Moving of the automatic variables to the heap in smooth shading functions is better left to the author.
Alex, > Moving of the automatic variables to the heap No, I believe that the automatic variables are small enough, and this belief is proved with other compilers. Need to know why your version of the compiler consumes the C stack too much. Please measure the stack size and the stack frame sizes.
Unless I missed something, there doesn't seem to be a lot of structures allocated as automatic variables except possibly in fill_quadrangle which is only instantiated five times. How much would recoding this (or other) shading fill to use explicit allocation save ? I do notice that the gsos2.def has a stack size of 131072. How bad would it be to use that on Windows ?
Ray, I believe that we allocate a 64K stack on Windows, and it must be more than enough. I did special calculations when coded this module. I guess something is wrong with the version of the compiler Alex uses. Maybe our makefiles wrongly recognize that version and set an improper options to the compiler of to the linker.
I also have the 12.00.8168 MSVC toolset and am not able to reproduce the C-stack overflow. Also Jack confirmed that the failure on linux no longer occurs.