Bug 690283

Summary: printing multiple xps files causes hangup during cleanup
Product: GhostXPS Reporter: norbert.janssen
Component: GeneralAssignee: 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
When printing multiple xps files (AC8Z11MS-MXDW.xps from Quality Logic), this
eventually caused a hangup in xpstop.c::xps_imp_dnit_job().
I traced it down to looping (round-robin) in  the "Free XPS parsing stuff",
caused by not setting ctx->first_part = NULL; after freeing all parts.
So the fix for me is:
    /* Free XPS parsing stuff */
    {
	xps_part_t *part = ctx->first_part;
	while (part)
	{
	    xps_part_t *next = part->next;
	    xps_free_part(ctx, part);
	    part = next;
	}
	ctx->first_part = NULL;         /* FIX: reset first_part */

	xps_free_fixed_pages(ctx);
	xps_free_fixed_documents(ctx);


Similar fix in xpsdoc.c::xps_free_used_parts()

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;
    }
    ctx->first_part = NULL;   /* FIX: reset first_part */
}
Comment 1 norbert.janssen 2009-02-11 01:11:34 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?
Comment 2 norbert.janssen 2009-02-11 05:11:00 UTC
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.
Comment 3 Tor Andersson 2009-02-11 12:54:55 UTC
It was an error in the allocation and freeing of the part table in the job init/deinit routines. Fixed in 
revision 9471.
Comment 4 Tor Andersson 2009-02-11 12:56:09 UTC
*** Bug 690267 has been marked as a duplicate of this bug. ***
Comment 5 norbert.janssen 2009-02-11 23:41:37 UTC
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;
    }
}