Summary: | printing multiple xps files causes hangup during cleanup | ||
---|---|---|---|
Product: | GhostXPS | Reporter: | norbert.janssen |
Component: | General | Assignee: | Tor Andersson <tor.andersson> |
Status: | NOTIFIED FIXED | ||
Severity: | normal | CC: | ralph.giles |
Priority: | P4 | ||
Version: | 1.54 | ||
Hardware: | PC | ||
OS: | All | ||
Customer: | 661 | Word Size: | --- |
Description
norbert.janssen
2009-02-11 01:08:17 UTC
It could also be that it is sufficient to set ctx->first_part = NULL; in xpstop.c::xps_imp_init_job(), but I'm not sure about that, because: start_part, last_part seem to point to current (last processing job), first_part is head of part-list, possibly containing multiple jobs? I re-checked with standard trunk build (revision 9647) with CYGWIN. make xps-debug in xps (after re-directing the x11 display) obj/gxps -sDEVICE=x11 AC8Z11MS-MXDW.xps AC8Z11MS-MXDW.xps sigsegv on start of second file. Implementing my fixes, prints 2 pages. It was an error in the allocation and freeing of the part table in the job init/deinit routines. Fixed in revision 9471. *** Bug 690267 has been marked as a duplicate of this bug. *** I noticed that only in xpstop.c changes were made. In xpsdoc.c the following function also uses ctx->first_part to free the list, but does not reset it. Is this intentionaly, or an ommission? void xps_free_used_parts(xps_context_t *ctx) { /* TODO: actually do what we should. for now we just free cached resources. */ xps_part_t *part = ctx->first_part; while (part) { xps_part_t *next = part->next; xps_free_part_caches(ctx, part); part = next; } } |