Bug 1416 - "x11perf -copypixpix500" crashes Xprt's PostScript DDX [PsCreateAndCopyGC
Summary: "x11perf -copypixpix500" crashes Xprt's PostScript DDX [PsCreateAndCopyGC
Status: RESOLVED FIXED
Alias: None
Product: xprint
Classification: Unclassified
Component: Server: DDX: PostScript (show other bugs)
Version: unspecified
Hardware: All All
: high blocker
Assignee: Roland Mainz
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-09-19 14:10 UTC by Roland Mainz
Modified: 2004-12-12 02:07 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Workaround (or fix ?) patch for 2004-09-19-trunk (7.67 KB, patch)
2004-09-19 14:45 UTC, Roland Mainz
roland.mainz: review? (jay.hobson)
Details | Splinter Review
Reduced testcase ("xprtcrash_bug1416.c") (1.86 KB, text/plain)
2004-10-03 00:07 UTC, Roland Mainz
no flags Details
[FIXED_X11R68x] New (workaround) patch for 2004-10-03-trunk (9.57 KB, patch)
2004-10-03 08:32 UTC, Roland Mainz
roland.mainz: 6.8-branch+
Details | Splinter Review

Description Roland Mainz 2004-09-19 14:10:21 UTC
Running "x11perf -copypixpix500" on Xprt's PS DDX crashes the
print server like this:
-- snip --
% dbx -c 'check -access ; suppress rui ; catch ABRT FPE ; run -pn -ac -fp
/usr/openwin/lib/X11/fonts/misc/ -audit 4 :18' ./Xprt
Reading Xprt
Reading ld.so.1
Reading libc.so.1
Reading libdl.so.1
Reading libc_psr.so.1
access checking - ON
Running: Xprt -pn -ac -fp /usr/openwin/lib/X11/fonts/misc/ -audit 4 :18 
(process id 29376)
Reading librtc.so
RTC: Enabling Error Checking...
RTC: Using UltraSparc trap mechanism
RTC: See `help rtc showmap' and `help rtc 8M' for details.
RTC: Running program...
Reading libsocket.so.1
Reading libnsl.so.1
Reading libmp.so.2
Reading libm.so.1
AUDIT: Tue May 13 17:01:26 2003: 29376 Xprt: client 1 connected from IP
141.50.42.191 port 46100
Read from unallocated (rua):
Attempting to read 4 bytes at address 0x18 in page zero
stopped in CopyGC at line 808 in file "gc.c"
  808                          pgcDst->tile.pixmap->refcnt++;
(dbx) where
=>[1] CopyGC(pgcSrc = 0xdabeb8, pgcDst = 0xd63150, mask = 8386560U), line 808 in
"gc.c"
  [2] PsCreateAndCopyGC(pDrawable = 0xd62ff0, pSrc = 0xdabeb8), line 391 in
"PsGC.c"
  [3] PsCloneDisplayElm(dst = 0xd62ff0, elm = 0xd7ad40, newElm = 0xd7ad6c, xoff
= 96, yoff = 96), line 310 in "PsPixmap.c"
  [4] PsCopyDisplayList(src = 0xd62ff0, dst = 0xd62ff0, xoff = 96, yoff = 96, x
= 96, y = 96, w = 500, h = 500), line 454 in "PsPixmap.c"
  [5] PsCopyArea(pSrc = 0xd62ff0, pDst = 0xd62ff0, pGC = 0xd62ac8, srcx = 0,
srcy = 0, width = 500, height = 500, dstx = 96, dsty = 96), line 439 in
"PsArea.c"
  [6] ProcCopyArea(client = 0xda8d50), line 1595 in "dispatch.c"
  [7] Dispatch(), line 304 in "dispatch.c"
  [8] main(argc = 8, argv = 0xffbee68c), line 364 in "main.c"
-- snip --
Comment 1 Roland Mainz 2004-09-19 14:45:28 UTC
Created attachment 946 [details] [review]
Workaround (or fix ?) patch for 2004-09-19-trunk
Comment 2 Roland Mainz 2004-09-19 15:15:26 UTC
Comment on attachment 946 [details] [review]
Workaround (or fix ?) patch for 2004-09-19-trunk

Requesting r= from Jay since I am not sure whether this is really the right
solution (I am using |xcalloc()| to ensure that the allocated memory is filled
with '0' and then check for the NULL-ptr in PSGC.c - but I am not sure whether
this is the real solution (I assume the hack makes Pixmap-->Pixmap copies a
NP-OP)).
Comment 3 Roland Mainz 2004-09-19 15:59:37 UTC
Another crash, this time I tried to execute plain old Netscape 4.x on Solaris on
a Xprt display on SuSE linux. This crashed Xprt while "valgrind" logged the
following error:
-- snip --
==4207== Invalid read of size 4
==4207==    at 0x80CF554: PsCreateFillElementList (PsPixmap.c:482)
==4207==    by 0x80C7F59: PsChangeClip (PsGC.c:306)
==4207==    by 0x808050B: dixChangeGC (gc.c:449)
==4207==    by 0x8080728: ChangeGC (gc.c:537)
==4207==    by 0x80809FE: CreateGC (gc.c:687)
==4207==    by 0x8079B1A: ProcCreateGC (dispatch.c:1573)
==4207==    by 0x8085551: SProcCreateGC (swapreq.c:584)
==4207==    by 0x80775D0: Dispatch (dispatch.c:455)
==4207==    by 0x805E1F4: main (main.c:442)
==4207==    by 0x403068AD: __libc_start_main (in /lib/libc.so.6)
==4207==    by 0x804C160: (within
/home/gismobile/projects/xorg/work002/xc/programs/Xserver/Xprt)
==4207==    Address 0x18 is not stack'd, malloc'd or free'd
-- snip --
Line PsPixmap.c:482 looks like this:
-- snip --
      if( !elm->gc->fgPixel ) continue;
-- snip --
Maybe another incarnation of this "|elm-gc| is NULL"-issue - if that's true my
patch is likely not the correct solution... ... ;-(

Jay ?
Comment 4 Roland Mainz 2004-09-19 16:22:25 UTC
... and the crash listed in comment #3 also happens with Mozilla1.8Alpha3 (e.g.
try % (DISPLAY=dpy_of_xprt:5 ./mozilla # ...).
The following quick hack patch works around that mess...
-- snip --
 PsElmPtr
 PsCreateFillElementList(PixmapPtr pix, int *nElms)
 {
   PsElmPtr        elms = (PsElmPtr)0;
   PsPixmapPrivPtr priv = (PsPixmapPrivPtr)pix->devPrivate.ptr;
   DisplayListPtr  disp = priv->dispList;
   PsArcEnum       styl;
 
   *nElms = 0;
   for(; disp ; disp=disp->next )
   {
     int           i;
     DisplayElmPtr elm = disp->elms;
 
     for( i=0 ; i<disp->nelms ; i++,elm++ )
     {
+      if( !elm->gc ) continue;
       if( !elm->gc->fgPixel ) continue;
       switch(elm->type)
       {
-- snip --
... which indicates that somewhere something forgets to fill |elm->gc| ... ;-(
Comment 5 Roland Mainz 2004-10-03 00:07:39 UTC
Created attachment 993 [details]
Reduced testcase ("xprtcrash_bug1416.c")

Reduced testcase ("xprtcrash_bug1416.c") which demonstrates the crash.
Comment 6 Roland Mainz 2004-10-03 08:32:22 UTC
Created attachment 994 [details] [review]
[FIXED_X11R68x] New (workaround) patch for 2004-10-03-trunk

Combined patch from attachment 946 [details] [review] and comment #4. It's still the old
workaround but I don't have a better solution and we urgendly need a fix for
the crash.
Onr side-effect is that pixmap-to-pixmap copies where srcpix==destpix may
likely be broken... ;-(
Comment 7 Roland Mainz 2004-10-03 08:35:59 UTC
Patch checked-in...

/cvs/xorg/xc/ChangeLog,v  <--  ChangeLog
new revision: 1.421; previous revision: 1.420
/cvs/xorg/xc/programs/Xserver/Xprint/ps/PsGC.c,v  <--  PsGC.c
new revision: 1.4; previous revision: 1.3
/cvs/xorg/xc/programs/Xserver/Xprint/ps/PsPixmap.c,v  <--  PsPixmap.c
new revision: 1.4; previous revision: 1.3
Mailing the commit message to xorg-commit@pdx.freedesktop.org...

... marking bug as FIXED.

I'll file a new bug for the now broken pixmap-to-pixmap copies... ;-(
Comment 8 Julien Lafon 2004-11-09 01:53:12 UTC
Comment on attachment 994 [details] [review]
[FIXED_X11R68x] New (workaround) patch for 2004-10-03-trunk

nominating for X11R6.8.2, the patch fixes a hole which can be used to crash the
XPrint server (DOS attack possible).
Comment 9 Roland Mainz 2004-11-19 07:35:46 UTC
Comment on attachment 994 [details] [review]
[FIXED_X11R68x] New (workaround) patch for 2004-10-03-trunk

Approved for the X11R6.8.x branch in the 2004-11-17 release-wranglers phone
call.
Please don't commit it yourself, I'll handle that once the CVS service is
available again.
Comment 10 Roland Mainz 2004-12-12 21:07:14 UTC
Comment on attachment 994 [details] [review]
[FIXED_X11R68x] New (workaround) patch for 2004-10-03-trunk

Patch checked-in into X11R6.8.x stable branch:

/cvs/xorg/xc/ChangeLog,v  <--  ChangeLog
new revision: 1.365.2.40; previous revision: 1.365.2.39
cvs commit: Using deprecated info format strings.  Convert your scripts to use
the new argument format and remove '1's from your info file format strings.
/cvs/xorg/xc/programs/Xserver/Xprint/ps/PsGC.c,v  <--  PsGC.c
new revision: 1.3.4.1; previous revision: 1.3
/cvs/xorg/xc/programs/Xserver/Xprint/ps/PsPixmap.c,v  <--  PsPixmap.c
new revision: 1.3.2.1; previous revision: 1.3
cvs commit: Using deprecated info format strings.  Convert your scripts to use
the new argument format and remove '1's from your info file format strings.
Mailing the commit message to xorg-commit@lists.freedesktop.org...


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.