Bug 465311
| Summary: | segfaults on x86_64 | |||
|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tom "spot" Callaway <tcallawa> | |
| Component: | ghostscript | Assignee: | Tim Waugh <twaugh> | |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | medium | |||
| Version: | 12 | CC: | daw-redhatbugzilla, twaugh | |
| Target Milestone: | --- | Keywords: | Reopened, Triaged | |
| Target Release: | --- | |||
| Hardware: | x86_64 | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | ghostscript-8.71-16.fc12 | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 629562 (view as bug list) | Environment: | ||
| Last Closed: | 2010-10-11 19:25:46 UTC | Type: | --- | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 629562, 629563 | |||
I can't really see anything wrong in the code, and I haven't been able to reproduce the problem myself. I rebuild ghostscript recently (it's now ghostscript-8.63-3.fc10). Can you still reproduce the problem in koji? I've just built ghostscript-8.63-4.fc10 with this patch:
--- ghostscript-8.63/src/iname.c.465311 2008-10-17 11:52:31.000000000 +0100
+++ ghostscript-8.63/src/iname.c 2008-10-17 11:53:08.000000000 +0100
@@ -415,7 +415,8 @@ names_trace_finish(name_table * nt, gc_s
if (nt->sub[i].names == 0 && gcst != 0) {
/* Mark the just-freed sub-table as unmarked. */
o_set_unmarked((obj_header_t *)sub - 1);
- o_set_unmarked((obj_header_t *)ssub - 1);
+ if (ssub != 0)
+ o_set_unmarked((obj_header_t *)ssub - 1);
}
}
if (i == 0)
It would be a useful data point to know whether that works around the problem.
Nope. It does not change the failure: http://koji.fedoraproject.org/koji/getfile?taskID=886345&name=build.log This is very strange, because I can only reproduce it in Fedora koji, not in a local build or local mock. I'm wondering if perhaps it is a resource constraint issue? This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. *** Bug 568554 has been marked as a duplicate of this bug. *** Re-opening and changing version to 12. Bug is observable using valgrind. Does anyone see this crash still with ghostscript-8.71-4.fc12? This has been fixed upstream. Patch backported in ghostscript-8.71-12.fc12. ghostscript-8.71-15.fc12 has been submitted as an update for Fedora 12. https://admin.fedoraproject.org/updates/ghostscript-8.71-15.fc12 ghostscript-8.71-14.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/ghostscript-8.71-14.fc13 ghostscript-8.71-15.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/ghostscript-8.71-15.fc14 ghostscript-8.71-15.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update ghostscript'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/ghostscript-8.71-15.fc14 ghostscript-8.71-16.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/ghostscript-8.71-16.fc14 ghostscript-8.71-16.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/ghostscript-8.71-16.fc13 ghostscript-8.71-16.fc12 has been submitted as an update for Fedora 12. https://admin.fedoraproject.org/updates/ghostscript-8.71-16.fc12 ghostscript-8.71-16.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. ghostscript-8.71-16.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. ghostscript-8.71-16.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report. |
One of my packages (lout) calls ps2pdf to generate documentation from some generated .ps files, and while this works fine for me locally (on a rawhide system) and in a f10 mock instance, when I try to build this through koji, the build fails because ps2pdf segfaults. See Bugzilla 465017 for the logs showing the ps2pdf segfault. Matt Domsch was able to reproduce this in his rawhide rebuilds, and got a gdb backtrace: Program received signal SIGSEGV, Segmentation fault. names_trace_finish (nt=0x607598, gcst=0x7fffffffe7d0) at src/iname.c:418 418 o_set_unmarked((obj_header_t *)ssub - 1); Missing separate debuginfos, use: debuginfo-install cairo.x86_64 cups.x86_64 e2fsprogs.x86_64 expat.x86_64 gcc.x86_64 glibc.x86_64 gnutls.x86_64 jasper.x86_64 keyutils.x86_64 krb5.x86_64 libICE.x86_64 libSM.x86_64 libX11.x86_64 libXau.x86_64 libXdmcp.x86_64 libXext.x86_64 libXrender.x86_64 libgcrypt.x86_64 libgpg-error.x86_64 libjpeg.x86_64 libpng.x86_64 libselinux.x86_64 libtasn1.x86_64 libtiff.x86_64 libxcb.x86_64 pixman.x86_64 zlib.x86_64 (gdb) bt #0 names_trace_finish (nt=0x607598, gcst=0x7fffffffe7d0) at src/iname.c:418 #1 0x00007ffff76aae32 in gs_gc_reclaim (pspaces=<value optimized out>, global=1) at src/igc.c:371 #2 0x00007ffff7721d87 in context_reclaim (pspaces=0x643948, global=1) at src/zcontext.c:283 #3 0x00007ffff7685060 in gs_vmreclaim () at src/ireclaim.c:153 #4 ireclaim (dmem=0x643940, space=8) at src/ireclaim.c:75 #5 0x00007ffff7680961 in interp_reclaim (pi_ctx_p=0x6028a8, space=8) at src/interp.c:427 #6 0x00007ffff767784c in gs_main_finit (minst=0x602810, exit_status=0, code=0) at src/imain.c:752 #7 0x00007ffff767b258 in gsapi_exit (lib=<value optimized out>) at src/iapi.c:262 #8 0x0000000000400a4c in main (argc=14, argv=<value optimized out>) at src/dxmainc.c:88 (gdb) list src/iname.c:418 413 if (sub != 0) { 414 name_scan_sub(nt, i, true); 415 if (nt->sub[i].names == 0 && gcst != 0) { 416 /* Mark the just-freed sub-table as unmarked. */ 417 o_set_unmarked((obj_header_t *)sub - 1); 418 o_set_unmarked((obj_header_t *)ssub - 1); 419 } 420 } 421 if (i == 0) 422 break; This backtrace implicates ghostscript as the culprit. Even though I can't actively reproduce this, I wanted to file it.