Bug 691976 - segfault with cups driver
segfault with cups driver
Status: RESOLVED FIXED
Product: Ghostscript
Classification: Unclassified
Component: PDF Interpreter
0.00
PC Linux
: P4 normal
Assigned To: Michael Vrhel
Bug traffic
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-16 03:24 PST by Sanjoy Mahajan
Modified: 2011-06-29 03:41 PDT (History)
5 users (show)

See Also:
Customer:
Word Size: ---


Attachments
stdin to the gs command (192.80 KB, application/unknown)
2011-02-16 03:24 PST, Sanjoy Mahajan
Details
patch (1.28 KB, patch)
2011-03-01 14:38 PST, Alex Cherepanov
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sanjoy Mahajan 2011-02-16 03:24:20 PST
Created attachment 7254 [details]
stdin to the gs command

I am using gs 9.01 (from Debian unstable on a Thinkpad T60.  The Debian version seems to be very close to vanilla 9.01, with just three patches that don't seem relevant to this issue).  I had a problem printing a file with cup, which I eventually traced to a failing call to ghostscript.  (See Debian bug #612975 for my report on almost the same problem with a different file and using gs 8.71.)

The minimal example is to feed the attached one-page pdf (6.pdf) as stdin to the following command line:

/usr/bin/gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -sDEVICE=cups -sstdout=%stderr -sOutputFile=%stdout -I/usr/share/cups/fonts -sMediaType=Automatic -sOutputType=0 -r600x600 -dcupsMediaType=-1 -dcupsBitsPerColor=8 -dcupsColorOrder=0 -dcupsColorSpace=17 -c -f -_ > /dev/null 2> gs.stderr < 6.pdf

gs segfaults

I rebuilt the packages without optimization and with debug symbols.  Here is the gdb backtrace:

Program received signal SIGSEGV, Segmentation fault.
0xb7879e41 in pdf14_compose_group (tos=0x8269a18, nos=0x80e7e68, maskbuf=0x0, 
    x0=597, x1=3723, y0=8, y1=17, n_chan=4, additive=1, 
    pblend_procs=0xb7bd3390) at ./base/gxblend1.c:303
303			    tos_pixel[i] = tos_ptr[x + i * tos_planestride];
(gdb) bt
#0  0xb7879e41 in pdf14_compose_group (tos=0x8269a18, nos=0x80e7e68, 
    maskbuf=0x0, x0=597, x1=3723, y0=8, y1=17, n_chan=4, additive=1, 
    pblend_procs=0xb7bd3390) at ./base/gxblend1.c:303
#1  0xb787c144 in pdf14_pop_transparency_group (pis=0xbfff92b8, 
    ctx=0x80e7e30, pblend_procs=0xb7bd3398, curr_num_color_comp=4, 
    curr_icc_profile=0x815f7d0, dev=0x81f0aa4) at ./base/gdevp14.c:943
#2  0xb78803cf in pdf14_end_transparency_group (dev=0x81f0aa4, 
    pis=0xbfff92b8, ppts=0x0) at ./base/gdevp14.c:3012
#3  0xb78738ae in gx_end_transparency_group (pis=0xbfff92b8, pdev=0x81f0aa4)
    at ./base/gstrans.c:421
#4  0xb787f7a2 in gx_update_pdf14_compositor (pdev=0x81f0aa4, pis=0xbfff92b8, 
    pdf14pct=0x80e7c30, mem=0x804b474) at ./base/gdevp14.c:2649
#5  0xb787f9ad in pdf14_create_compositor (dev=0x81f0aa4, pcdev=0xbfff7d28, 
    pct=0x80e7c30, pis=0xbfff92b8, mem=0x804b474, cdev=0xb6b4803c)
    at ./base/gdevp14.c:2728
#6  0xb78d3c10 in apply_create_compositor (cdev=0xb6b4803c, pis=0xbfff92b8, 
    mem=0x804b474, pcomp=0x80e7c30, x0=0, y0=3621, ptarget=0xbfffb3bc)
    at ./base/gxclrast.c:2749
#7  0xb78cce10 in execute_compositor_queue (cdev=0xb6b4803c, 
    target=0xbfffb3bc, tdev=0xbfffa234, pis=0xbfff92b8, 
    ppcomp_first=0xbfff8570, ppcomp_last=0xbfff856c, pcomp_from=0x0, x0=0, 
    y0=3621, mem=0x804b474, idle=0) at ./base/gxclrast.c:381
#8  0xb78cfffa in clist_playback_band (
    playback_action=playback_action_render, cdev=0xb6b4803c, s=0xbfffc3dc, 
    target=0x81f0aa4, x0=0, y0=3621, mem=0x804b474) at ./base/gxclrast.c:1514
#9  0xb78d6741 in clist_playback_file_bands (action=playback_action_render, 
    crdev=0xb6b4803c, page_info=0xbfffd01c, target=0x80aa970, band_first=213, 
    band_last=213, x0=0, y0=3621) at ./base/gxclread.c:835
#10 0xb78d6507 in clist_render_rectangle (cldev=0xb6b4803c, prect=0xbfffd510, 
    bdev=0x80aa970, render_plane=0xbfffd61c, clear=1) at ./base/gxclread.c:764
#11 0xb78d62ad in clist_rasterize_lines (dev=0xb6b4803c, y=3621, 
    line_count=1, bdev=0x80aa970, render_plane=0xbfffd61c, pmy=0xbfffd618)
    at ./base/gxclread.c:676
#12 0xb78d5e1c in clist_get_bits_rectangle (dev=0xb6b4803c, prect=0xbfffd868, 
    params=0xbfffd7d8, unread=0x0) at ./base/gxclread.c:567
#13 0xb78e8fa8 in clist_get_bits_rect_mt (dev=0xb6b4803c, prect=0xbfffd868, 
    params=0xbfffd7d8, unread=0x0) at ./base/gxclthrd.c:512
#14 0xb7af7fc8 in gx_default_get_bits (dev=0xb6b4803c, y=3621, 
    data=0x84de740 "", actual_data=0xbfffd8f8) at ./base/gdevdgbr.c:51
#15 0xb78c7ee2 in gdev_prn_get_bits (pdev=0xb6b4803c, y=3621, 
    str=0x84de740 "", actual_data=0xbfffd8f8) at ./base/gdevprn.c:1230
#16 0xb7a68241 in cups_print_chunked (pdev=0xb6b4803c, src=0x84de740 "", 
    dst=0x84e86c0 "", srcbytes=40800) at cups/gdevcups.c:4131
#17 0xb7a6454f in cups_print_pages (pdev=0xb6b4803c, fp=0xb76d94c0, 
    num_copies=1) at cups/gdevcups.c:2854
#18 0xb78c7056 in gdev_prn_output_page (pdev=0xb6b4803c, num_copies=1, 
    flush=1) at ./base/gdevprn.c:771
#19 0xb7afabc5 in gx_forward_output_page (dev=0x81efa2c, num_copies=1, 
    flush=1) at ./base/gdevnfwd.c:174
#20 0xb7a810f7 in gs_output_page (pgs=0x80652b4, num_copies=1, flush=1)
    at ./base/gsdevice.c:147
#21 0xb78285fb in zoutputpage (i_ctx_p=0x8075a28) at ./psi/zdevice.c:355
#22 0xb77f03b1 in interp (pi_ctx_p=0x804a1e4, pref=0xbfffe684, 
    perror_object=0xbfffe820) at ./psi/interp.c:1526
#23 0xb77edfe3 in gs_call_interp (pi_ctx_p=0x804a1e4, pref=0xbfffe778, 
    user_errors=1, pexit_code=0xbfffe828, perror_object=0xbfffe820)
    at ./psi/interp.c:484
#24 0xb77ede6e in gs_interpret (pi_ctx_p=0x804a1e4, pref=0xbfffe778, 
    user_errors=1, pexit_code=0xbfffe828, perror_object=0xbfffe820)
    at ./psi/interp.c:442
#25 0xb77e3662 in gs_main_interpret (minst=0x804a190, pref=0xbfffe778, 
    user_errors=1, pexit_code=0xbfffe828, perror_object=0xbfffe820)
    at ./psi/imain.c:240
#26 0xb77e414a in gs_main_run_string_end (minst=0x804a190, user_errors=1, 
    pexit_code=0xbfffe828, perror_object=0xbfffe820) at ./psi/imain.c:556
#27 0xb77e4027 in gs_main_run_string_with_length (minst=0x804a190, 
    str=0xb7b1b04e ".runstdin", length=9, user_errors=1, 
    pexit_code=0xbfffe828, perror_object=0xbfffe820) at ./psi/imain.c:514
#28 0xb77e3f85 in gs_main_run_string (minst=0x804a190, 
    str=0xb7b1b04e ".runstdin", user_errors=1, pexit_code=0xbfffe828, 
    perror_object=0xbfffe820) at ./psi/imain.c:496
#29 0xb77e6947 in run_string (minst=0x804a190, str=0xb7b1b04e ".runstdin", 
    options=2) at ./psi/imainarg.c:814
#30 0xb77e546e in swproc (minst=0x804a190, arg=0xbffffc57 "", pal=0xbfffef68)
    at ./psi/imainarg.c:282
#31 0xb77e5178 in gs_main_init_with_args (minst=0x804a190, argc=19, 
    argv=0xbffff9a4) at ./psi/imainarg.c:200
#32 0xb77e82eb in gsapi_init_with_args (lib=0x804a108, argc=19, 
    argv=0xbffff9a4) at ./psi/iapi.c:173
#33 0x0804891e in main (argc=19, argv=0xbffff9a4) at ./psi/dxmainc.c:84
Comment 1 Till Kamppeter 2011-02-24 21:29:09 PST
Looks like a problem of the PDF interpreter for me ...
Comment 2 Till Kamppeter 2011-02-24 21:46:18 PST
segafults also with GS 9.01, also the file attached to bug #691981 segfaults.
Comment 3 Ken Sharp 2011-02-28 13:39:03 PST
(In reply to comment #1)
> Looks like a problem of the PDF interpreter for me ...

For me this seg faults on Windows with simply "-sDEVICE=cups -dcupsColorSpace=17" (this requires a recent version of GS in order to have the cups device on Windows) so it looks like the problem is one of the wacky colour spaces associated with the CUPS device. I guess that the transparency compositor doesn't know how to deal with the particular colour space.

For me the crash occurs in (call stack) :

pdf14_compose_group
pdf14_pop_transparency_group
pdf14_end_transparency group
gx_end_transparency_group
gx_update_pdf14_compositor

Which looks identical to the stack trace supplied in comment #0

The problem is that tos->data is 0x000000, and reading from that location results in an invalid memory access. I'm afraid I don't know enough about the transparency compositor to offer anything more useful though.
Comment 4 Alex Cherepanov 2011-03-01 14:38:01 PST
Created attachment 7298 [details]
patch

This patch fixes the SEGV by following the logic of the program and not
the memory when it is not allocated. Probably, there's deeper problem
in the affected code. The 1st hunk of the patch just changes misleading
formatting.
Comment 5 Alex Cherepanov 2011-03-01 14:41:00 PST
Michael, please review the patch and the surrounding code.
Comment 6 Michael Vrhel 2011-04-09 05:49:41 PDT
Alex, thanks for the patch.  I will take a closer look at this next week.
Comment 7 Michael Vrhel 2011-06-28 15:17:54 PDT
This runs fine for me with head on my 32bit Ubuntu.  Alex can you double check?
Comment 8 Till Kamppeter 2011-06-28 15:32:40 PDT
9.02 on Ubuntu Oneiric 64-bit still segfaults, but I do not know whether it already contains the patch.
Comment 9 Michael Vrhel 2011-06-28 17:33:43 PDT
Hmmm.  I misran the command line ignore my earlier post.
Comment 10 Alex Cherepanov 2011-06-29 03:41:59 PDT
The problem is reproduced in v. 9.01 and 9.02 but it is fixed in the current development code.

The problem was fixed in the trunk on 2011-05-19 with the merge of pat_trans_clist branch, commit 44e59fd123729ba05f8728f01d13406d3e283855.

The problem was first fixed on a branch with a similar patch on 2011-02-09 by a commit ebf1da59669bb51701c3df9747ebe3f4fe9f6b26, "Work on the pattern transparency clist code".

Surprisingly, two programmers have independently come to the same solution.
The fix on the branch was made even earlier than the bug was reported.
The case is closed.