Bug 7346

Summary:

segfault in composite due to xprint/ps lack of WindowPixmap

Product:

xorg

Reporter:

Drew Parsons <dparsons>

Component:

Server/General

Assignee:

Xorg Project Team <xorg-team>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

high

Keywords:

patch

Version:

git

Hardware:

x86 (IA32)

OS:

Linux (All)

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
patch heals composite WindowPixmap segfault	none
marks composite extension as unsupported by Xprint	none

Description Drew Parsons 2006-06-27 21:39:16 UTC

Compilation of Xprint from current git results in a segfault in Xprt when
attempting to print.  A short backtrace looks like:
#0  0x00000000 in ?? ()
#1  0x080bc2ee in compCreateWindow (pWin=0x875e6e8) at compwindow.c:600

l.600 in xserver/composite/compwindow.c says:
   (*pScreen->SetWindowPixmap) (pWin, (*pScreen->GetWindowPixmap) (pWin->parent));
so the crash occurs because the ps module under Xprint does not use or define
GetWindowPixmap or SetWindowPixmap.  ajax advises that the ps component tries
not to rasterise images, keeping them in vector form as preferred for postscript
output, so the behaviour makes sense.  ajax suggests adding an empty stub
implementation of the functions to ps could workaround the issue.

An alternate solution is to check the functions are defined before running
l.600.  There is precedent for this approach in miext/damage/damage.c, which
does precisely that in l.85 "if (pScreen->GetWindowPixmap...".

I therefore propose patching compwindow.c in a similar way. An advantage of this
approach is that it frees other future components which may also want to use a
vector-oriented paradigm to similarly not have to provide a stub implementation
of [GS]etWindowPixmap.

My patch is attached, it restores Xprt back to working order.

Comment 1 Drew Parsons 2006-06-27 21:40:38 UTC

Created attachment 6066 [details] [review]
patch heals composite WindowPixmap segfault

Comment 2 Eric Anholt 2006-07-06 17:30:03 UTC

The correct fix (avoiding various snarky comments) would be to make XPrint not
try to initialize an extension it has no hope of supporting.

Comment 3 Drew Parsons 2006-07-06 17:40:02 UTC

OK, thanks for the feedback.  I'll generate a different patch operating on
Xprint directly then.  Either in the Xprint code itself, or setting up a
--disable-composite inside the XPRINT block in configure.ac.

Comment 4 Drew Parsons 2006-07-10 22:12:36 UTC

I think the following patch must be the one we want.  Xprint keeps a list of the
extensions it does not support in mi/miinitext.c.  Since the composite extension
is relatively new, it hadn't been registered as unsupported.  The patch adds it
to the list.

Composite still gets compiled, but is not used by Xprint so the crash reported
in this bug is avoided.  The binary size can be made slightly (1%) smaller by
not compiling it.  Doing this by default for Xprint means complicating
configure.ac to a messy degree in order to undo the normal xserver default of
including composite. So I recommend not touching configure.ac in this way. If
saving the unused space is really that important to someone then
--disable-composite (along with --disable-damage and other extensions not
supported by Xprint) can be applied explicitly at build time.

Comment 5 Drew Parsons 2006-07-10 22:14:05 UTC

Created attachment 6184 [details] [review]
marks composite extension as unsupported by Xprint

Adds composite to the list of extensions unsupported by Xprint.

Comment 6 Alan Coopersmith 2006-07-11 18:30:36 UTC

Second patch (disable composite in Xprint) applied to Xorg git head:

 mi/miinitext.c |    1 +
 1 files changed, 1 insertion(+)

New commits:
diff-tree bb3aa94845a74d7718ba9539bb76203ec82957fc (from
10f3e32726d5b4981abd1a3a022e5b4f219fb41e)
Author: Drew Parsons <dparsons@debian.org>
Date:   Tue Jul 11 18:26:55 2006 -0700

    Bug #7346: Disable Composite extension in Xprt
    
    Xorg Bug #7346 <https://bugs.freedesktop.org/show_bug.cgi?id=7346>
    Patch #6184 <https://bugs.freedesktop.org/attachment.cgi?id=6184>

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.