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.
Created attachment 6066 [details] [review] patch heals composite WindowPixmap segfault
The correct fix (avoiding various snarky comments) would be to make XPrint not try to initialize an extension it has no hope of supporting.
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.
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.
Created attachment 6184 [details] [review] marks composite extension as unsupported by Xprint Adds composite to the list of extensions unsupported by Xprint.
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.