Many of the XPS regression fails seg fault with -sDEVICE=pgmraw with the current GhostXPS code (r10085). These errors come and go on various machines, but appear consistently enough that the cause shouldn't be too difficult to find. Here's a non-exhaustive list of files that have exhibited this problem: tests_private/xps/xpsfts-a4/fts_01xx.xps tests_private/xps/xpsfts-a4/fts_06xx.xps tests_private/xps/xpsfts-a4/fts_09xx.xps tests_private/xps/xpsfts-a4/fts_17xx.xps tests_private/xps/xpsfts-a4/fts_19xx.xps tests_private/xps/xpsfts-a4/fts_23xx.xps tests_private/xps/xpsfts-a4/fts_24xx.xps Here's a sample command line: xps/obj/gxps -sOutputFile=test.pgm -sDEVICE=pgmraw -r72 -dNOPAUSE ./fts_01xx.xps
Valgrind output: marcos@i7:[19]% valgrind xps/obj/gxps -sOutputFile=test.pgm -sDEVICE=pgmraw -r72 -dNOPAUSE ./fts_01xx.xps ==23104== Memcheck, a memory error detector. ==23104== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al. ==23104== Using LibVEX rev 1884, a library for dynamic binary translation. ==23104== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. ==23104== Using valgrind-3.4.1-Debian, a dynamic binary instrumentation framework. ==23104== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. ==23104== For more details, rerun with: -v ==23104== xps: page /Documents/1/Pages/1.fpage has transparency GPL Ghostscript SVN PRE-RELEASE 8.71: Some glyphs of the font CourierNewPSMT requires a patented True Type interpreter. GPL Ghostscript SVN PRE-RELEASE 8.71: Some glyphs of the font ArialMT requires a patented True Type interpreter. GPL Ghostscript SVN PRE-RELEASE 8.71: Some glyphs of the font TimesNewRomanPSMT requires a patented True Type interpreter. xps: page /Documents/1/Pages/2.fpage has transparency xps: page /Documents/1/Pages/3.fpage has transparency xps: page /Documents/1/Pages/4.fpage has transparency ==23104== Invalid read of size 8 ==23104== at 0x494A9D: shade_init_fill_state (gxshade.c:354) ==23104== by 0x4998C9: gs_shading_R_fill_rectangle_aux (gxshade1.c:1067) ==23104== by 0x49A2CC: gs_shading_R_fill_rectangle (gxshade1.c:1142) ==23104== by 0x493CB5: gs_shading_do_fill_rectangle (gsshade.c:475) ==23104== by 0x492332: gx_dc_pattern2_fill_rectangle (gsptype2.c:232) ==23104== by 0x6A7F09: gx_default_fill_path (gxfill.c:621) ==23104== by 0x4BD709: pdf14_fill_path (gdevp14.c:1561) ==23104== by 0x6CFF45: gx_fill_path (gxpaint.c:48) ==23104== by 0x48FB43: gs_shfill (gscolor3.c:111) ==23104== by 0x71EA28: xps_draw_one_radial_gradient (xpsgradient.c:374) ==23104== by 0x71F0FC: xps_draw_radial_gradient (xpsgradient.c:538) ==23104== by 0x71FEFC: xps_parse_gradient_brush (xpsgradient.c:771) ==23104== Address 0xc8 is not stack'd, malloc'd or (recently) free'd ==23104== ==23104== Process terminating with default action of signal 11 (SIGSEGV) ==23104== Access not within mapped region at address 0xC8 ==23104== at 0x494A9D: shade_init_fill_state (gxshade.c:354) ==23104== by 0x4998C9: gs_shading_R_fill_rectangle_aux (gxshade1.c:1067) ==23104== by 0x49A2CC: gs_shading_R_fill_rectangle (gxshade1.c:1142) ==23104== by 0x493CB5: gs_shading_do_fill_rectangle (gsshade.c:475) ==23104== by 0x492332: gx_dc_pattern2_fill_rectangle (gsptype2.c:232) ==23104== by 0x6A7F09: gx_default_fill_path (gxfill.c:621) ==23104== by 0x4BD709: pdf14_fill_path (gdevp14.c:1561) ==23104== by 0x6CFF45: gx_fill_path (gxpaint.c:48) ==23104== by 0x48FB43: gs_shfill (gscolor3.c:111) ==23104== by 0x71EA28: xps_draw_one_radial_gradient (xpsgradient.c:374) ==23104== by 0x71F0FC: xps_draw_radial_gradient (xpsgradient.c:538) ==23104== by 0x71FEFC: xps_parse_gradient_brush (xpsgradient.c:771) ==23104== If you believe this happened as a result of a stack overflow in your ==23104== program's main thread (unlikely but possible), you can try to increase ==23104== the size of the main thread stack using the --main-stacksize= flag. ==23104== The main thread stack size used in this run was 8388608. ==23104== ==23104== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 8 from 1) ==23104== malloc/free: in use at exit: 10,019,824 bytes in 162 blocks. ==23104== malloc/free: 1,244 allocs, 1,082 frees, 24,019,502 bytes allocated. ==23104== For counts of detected errors, rerun with: -v ==23104== searching for pointers to 162 not-freed blocks. ==23104== checked 16,380,952 bytes. ==23104== ==23104== LEAK SUMMARY: ==23104== definitely lost: 0 bytes in 0 blocks. ==23104== possibly lost: 0 bytes in 0 blocks. ==23104== still reachable: 10,019,824 bytes in 162 blocks. ==23104== suppressed: 0 bytes in 0 blocks. ==23104== Rerun with --leak-check=full to see details of leaked memory. Segmentation fault
And gdb stacktrace: #0 0x0000000000494a9d in shade_init_fill_state (pfs=0x7fffc746fcc0, psh=0x23a5030, dev=0x7fffc74706b0, pis=0x24a5800) at ../gs/base/gxshade.c:354 #1 0x00000000004998ca in gs_shading_R_fill_rectangle_aux (psh0=0x23a5030, rect=0x7fffc746ffd0, clip_rect=0x7fffc7470010, dev=0x7fffc74706b0, pis=0x24a5800) at ../gs/base/gxshade1.c:1067 #2 0x000000000049a2cd in gs_shading_R_fill_rectangle (psh0=0x23a5030, rect=0x7fffc746ffd0, rect_clip=0x7fffc7470010, dev=0x7fffc74706b0, pis=0x24a5800) at ../gs/base/gxshade1.c:1142 #3 0x0000000000493cb6 in gs_shading_do_fill_rectangle (psh=0x23a5030, prect=0x7fffc7470370, dev=0x7fffc74706b0, pis=0x24a5800, fill_background=0) at ../gs/base/gsshade.c:475 #4 0x0000000000492333 in gx_dc_pattern2_fill_rectangle (pdevc=0x7fffc74713a0, x=15, y=449, w=283, h=378, dev=0x7fffc74706b0, lop=16636, source=0x0) at ../gs/base/gsptype2.c:232 #5 0x00000000006a7f0a in gx_default_fill_path (pdev=0x2420208, pis=0x7fffc7470dc0, ppath=0x0, params=0x7fffc7471230, pdevc=0x7fffc74713a0, pcpath=0x234d470) at ../gs/base/gxfill.c:621 #6 0x00000000004bd70a in pdf14_fill_path (dev=0x2420208, pis=0x2214d88, ppath=0x0, params=0x7fffc7471230, pdcolor=0x7fffc74713a0, pcpath=0x234d470) at ../gs/base/gdevp14.c:1561 #7 0x00000000006cff46 in gx_fill_path (ppath=0x0, pdevc=0x7fffc74713a0, pgs=0x2214d88, rule=-1, adjust_x=0, adjust_y=0) at ../gs/base/gxpaint.c:48 #8 0x000000000048fb44 in gs_shfill (pgs=0x2214d88, psh=0x23a5030) at ../gs/base/gscolor3.c:111 #9 0x000000000071ea29 in xps_draw_one_radial_gradient (ctx=0x2214018, func=0x23a5658, extend=1, x0=96, y0=24, r0=0, x1=100, y1=24, r1=50) at ../xps/xpsgradient.c:374 #10 0x000000000071f0fd in xps_draw_radial_gradient (ctx=0x2214018, root=0x24ed210, spread=0, func=0x23a5658) at ../xps/xpsgradient.c:538 #11 0x000000000071fefd in xps_parse_gradient_brush (ctx=0x2214018, dict=0x239cfe8, root=0x24ed210, draw=0x71ec4a <xps_draw_radial_gradient>) at ../xps/xpsgradient.c:771 #12 0x00000000007200f4 in xps_parse_radial_gradient_brush (ctx=0x2214018, dict=0x239cfe8, root=0x24ed210) at ../xps/xpsgradient.c:822 #13 0x0000000000715eec in xps_parse_brush (ctx=0x2214018, dict=0x239cfe8, node=0x24ed210) at ../xps/xpscommon.c:30 #14 0x00000000007177e7 in xps_begin_opacity (ctx=0x2214018, dict=0x239cfe8, opacity_att=0x0, opacity_mask_tag=0x24ed210) at ../xps/xpsopacity.c:59 #15 0x000000000071509c in xps_parse_canvas (ctx=0x2214018, dict=0x239cfe8, root=0x2347408) at ../xps/xpspage.c:83 #16 0x0000000000715fcf in xps_parse_element (ctx=0x2214018, dict=0x239cfe8, node=0x2347408) at ../xps/xpscommon.c:42 #17 0x00000000007150c5 in xps_parse_canvas (ctx=0x2214018, dict=0x239cfe8, root=0x2347f18) at ../xps/xpspage.c:87 #18 0x0000000000715fcf in xps_parse_element (ctx=0x2214018, dict=0x0, node=0x2347f18) at ../xps/xpscommon.c:42 #19 0x00000000007150c5 in xps_parse_canvas (ctx=0x2214018, dict=0x0, root=0x23a5d50) at ../xps/xpspage.c:87 #20 0x0000000000715fcf in xps_parse_element (ctx=0x2214018, dict=0x0, node=0x23a5d50) at ../xps/xpscommon.c:42 #21 0x00000000007157b5 in xps_parse_fixed_page (ctx=0x2214018, part=0x24dd440) at ../xps/xpspage.c:226 #22 0x0000000000714d56 in xps_process_part (ctx=0x2214018, part=0x24dd3d0) at ../xps/xpsdoc.c:922 #23 0x000000000071225f in xps_process_data (ctx=0x2214018, buf=0x7fffc7474060) at ../xps/xpszip.c:553 #24 0x0000000000404d0b in xps_imp_process (pinstance=0x2213fa0, pcursor=0x7fffc7474060) at ../xps/xpstop.c:224 #25 0x00000000007489b7 in pl_process (instance=0x2213fa0, cursor=0x7fffc7474060) at ../pl/pltop.c:148 #26 0x0000000000753c21 in pl_main (argc=6, argv=0x7fffc7474eb8) at ../pl/plmain.c:399 #27 0x0000000000755c8b in main (argc=6, argv=0x7fffc7474eb8) at ../pl/plmain.c:1280
I'm going to temporarily disable pgmraw testing with GhostXPS. Please let me know when this issue is resolved and I'll re-enable it.
I do not have all the test files listed but the pgmraw device worked fine on all the test files I have using the HEAD code. Is it possible to turn this back on see if this problem still exists?
Believed fix with: commit faea7d6e98d6e7ee0b82d891544a13d703a291f5 Author: Robin Watts <robin.watts@artifex.com> Date: Wed Sep 11 18:47:45 2013 +0100 Bug 690790: Workaround libpng 64bit build bug. libpng keeps a jmpbuf in it's structure. jmp_bufs have to be 16 byte aligned on x64 systems, and the png allocator makes no effort to align the buffer. The workaround here changes the PNG allocator to allocate it's main structure in a larger block than it needs, and to actually use a block in the middle of this to ensure alignment. A pointer is kept to the real address of the block for freeing.