Version-Release number of selected component: ghostscript-9.10-4.fc19 Additional info: reporter: libreport-2.1.9 backtrace_rating: 4 cmdline: gs -q -dNOPAUSE -dBATCH -dSAFER -sDEVICE=ps2write -sOUTPUTFILE=%stdout -dLanguageLevel=3 -r600 -dCompressFonts=false -dNoT3CCITT -dNOINTERPOLATE -c 'save pop' -f /var/spool/cups/tmp/cups0Yb3Cx crash_function: igc_reloc_struct_ptr executable: /usr/bin/gs kernel: 3.11.9-200.fc19.x86_64 runlevel: N 5 type: CCpp uid: 4 Truncated backtrace: Thread no. 1 (10 frames) #0 igc_reloc_struct_ptr at psi/igc.c:1305 #1 pdf14_device_reloc_ptrs at base/gdevp14.c:514 #2 gc_do_reloc at psi/igc.c:1247 #3 gs_gc_reclaim at psi/igc.c:449 #4 context_reclaim at psi/zcontext.c:280 #5 gs_vmreclaim at psi/ireclaim.c:155 #6 ireclaim at psi/ireclaim.c:77 #7 interp_reclaim at psi/interp.c:441 #8 interp at psi/interp.c:1713 #9 gs_call_interp at psi/interp.c:510
Created attachment 834524 [details] File: backtrace
Created attachment 834525 [details] File: cgroup
Created attachment 834526 [details] File: core_backtrace
Created attachment 834527 [details] File: dso_list
Created attachment 834528 [details] File: environ
Created attachment 834529 [details] File: exploitable
Created attachment 834530 [details] File: limits
Created attachment 834531 [details] File: maps
Created attachment 834532 [details] File: open_fds
Created attachment 834533 [details] File: proc_pid_status
Created attachment 834534 [details] File: var_log_messages
Are you able to reproduce this problem by e.g. printing the same job again? If so, are you able to share the content of that job? I can't reproduce this by running that command line with no input, so I think it must be triggered by something in the input job. That job would be a PDF file I expect, as the command line looks like something the CUPS pdftops filter would run.
(In reply to Tim Waugh from comment #12) > Are you able to reproduce this problem by e.g. printing the same job again? > If so, are you able to share the content of that job? > > I can't reproduce this by running that command line with no input, so I > think it must be triggered by something in the input job. That job would be > a PDF file I expect, as the command line looks like something the CUPS > pdftops filter would run. I can reproduce this by printing http://sgallagh.wordpress.com/2013/12/09/proposal-freeipa-role-for-fedora-servers/ from Firefox (with AFAICS default settings). I still have three PDF files in the CUPS queue, will attach them.
Created attachment 834719 [details] d00058-001
Created attachment 834720 [details] d00059-001
Created attachment 834721 [details] d00062-001
Thanks. I can reproduce this with d00062-001 on F20, but not on F19 -- even though both are built from the same git revision. I have found that the upstream 'ghostscript-9.10' tag builds a gs that crashes, but 'master' does not crash, so I'll start a bisect run.
Created attachment 834811 [details] gs-bisected.patch "git bisect" found this one to be the fix.
ghostscript-9.10-5.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/ghostscript-9.10-5.fc19
ghostscript-9.10-5.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/ghostscript-9.10-5.fc20
Package ghostscript-9.10-5.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing ghostscript-9.10-5.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-23146/ghostscript-9.10-5.fc19 then log in and leave karma (feedback).
ghostscript-9.10-5.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
ghostscript-9.10-5.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.