Bug 15878 - Using -wm option causes server to SEGV
Summary: Using -wm option causes server to SEGV
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: xorg-7.4
  Show dependency treegraph
 
Reported: 2008-05-08 14:23 UTC by James Cloos
Modified: 2008-05-17 07:18 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Xorg log (30.66 KB, text/plain)
2008-05-08 14:23 UTC, James Cloos
no flags Details
Xorg log file (30.66 KB, text/plain)
2008-05-09 05:47 UTC, James Cloos
no flags Details
STDERR output from xinit (2.26 KB, text/plain)
2008-05-09 05:47 UTC, James Cloos
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description James Cloos 2008-05-08 14:23:06 UTC
Created attachment 16435 [details]
Xorg log

While trying to test an app which requires backing store to properly render I discovered that any attempt to start the server with -wm causes a SEGV.  This occurred even with the default -bs (although the attached log was with +bs).
Comment 1 James Cloos 2008-05-08 14:53:40 UTC
My net connection sucks at the moment; I can’t do any significantly large uploads.  (I’m stuck with dialup here and it looks like the remote AS is negotiating an invalid MTU.)

I intended to attach the Xorg.0.log, xsession’s output and the conf; I’ll do so as soon as uploading is stable.
Comment 2 James Cloos 2008-05-09 05:47:01 UTC
Created attachment 16453 [details]
Xorg log file
Comment 3 James Cloos 2008-05-09 05:47:48 UTC
Created attachment 16454 [details]
STDERR output from xinit
Comment 4 James Cloos 2008-05-12 00:03:57 UTC
I compiled a copy with -ggdb and ran Xepher in gdb and found this:

The backtrace is:

0x0822edca in compNewPixmap (pWin=0x83c5290, x=0, y=0, w=640, h=480) at compalloc.c:474
474	    if (pParent->drawable.depth == pWin->drawable.depth)
(gdb) where
#0  0x0822edca in compNewPixmap (pWin=0x83c5290, x=0, y=0, w=640, h=480) at compalloc.c:474
#1  0x0822f0e1 in compAllocPixmap (pWin=0x83c5290) at compalloc.c:543
#2  0x0822c504 in compCheckRedirect (pWin=0x83c5290) at compwindow.c:161
#3  0x0822c85b in compRealizeWindow (pWin=0x83c5290) at compwindow.c:242
#4  0x080ab937 in MapWindow (pWin=0x83c5290, client=0x82c0ff0) at window.c:2766
#5  0x080a66fc in InitRootWindow (pWin=0x83c5290) at window.c:492
#6  0x080a1bc8 in main (argc=4, argv=0xbfd36324, envp=0xbfd36338) at main.c:414
(gdb) p pWin
$1 = (WindowPtr) 0x83c5290
(gdb) p *pWin
$2 = {drawable = {type = 0 '\0', class = 1 '\001', depth = 24 '\030', bitsPerPixel = 32 ' ', 
    id = 141, x = 0, y = 0, width = 640, height = 480, pScreen = 0x82c53c0, serialNumber = 4}, 
  devPrivates = 0x8532ca0, parent = 0x0, nextSib = 0x0, prevSib = 0x0, firstChild = 0x0, 
  lastChild = 0x0, clipList = {extents = {x1 = 0, y1 = 0, x2 = 640, y2 = 480}, data = 0x0}, 
  borderClip = {extents = {x1 = 0, y1 = 0, x2 = 640, y2 = 480}, data = 0x0}, valdata = 0x0, 
  winSize = {extents = {x1 = 0, y1 = 0, x2 = 640, y2 = 480}, data = 0x0}, borderSize = {
    extents = {x1 = 0, y1 = 0, x2 = 640, y2 = 480}, data = 0x0}, origin = {x = 0, y = 0}, 
  borderWidth = 0, deliverableEvents = 0, eventMask = 0, background = {pixmap = 0x8530c48, 
    pixel = 139660360}, border = {pixmap = 0x0, pixel = 0}, backStorage = 0x1, 
  optional = 0x83c5318, backgroundState = 3, borderIsPixel = 1, cursorIsNone = 0, 
  backingStore = 1, saveUnder = 0, DIXsaveUnder = 0, bitGravity = 0, winGravity = 1, 
  overrideRedirect = 0, visibility = 3, mapped = 1, realized = 1, viewable = 1, 
  dontPropagate = 0, forcedBS = 1, redirectDraw = 0, forcedBG = 0}


As you can see, MapWindow ends up calling CompNewPixmap with a pWin struct which has a NULL parent, and thus the dereference in pParent->drawable.depth causes the crash.

That call to CompNewPixmap never happens for the root window if -wm is not specified.

So, here is the interesting bit.  dix/window.c’s MapWindow() only calls compRealizeWindow() (by way of: « (*pScreen->RealizeWindow)(pWin); ») iff pWin->parent is NULL.  And even when run w/o -wm the RealizeWindow member of the pScreen struct still points to compRealizeWindow.

Comment 5 James Cloos 2008-05-12 00:07:36 UTC
I just pushed a fix in commit 04211c3532ca078420e3745a5eac3d9de120bc32.

I believe this should be cherry picked for the 1.4 and 1.5 branches,
so I'll leave it as ASSIGNED until that is decided.

With the patch the BackingStore-dependent program which led me to try +bs -wm works as its author intends.  (Or at least as its docs describe. ;^)

Comment 6 James Cloos 2008-05-12 00:14:15 UTC
Nominating commit 04211c3532ca078420e3745a5eac3d9de120bc32 for 1.4 and 1.5 branches of xserver.
Comment 7 Daniel Stone 2008-05-16 09:51:27 UTC
cherry-picked to 1.4 branch.
Comment 8 Julien Cristau 2008-05-17 07:18:45 UTC
ajax cherry-picked this on server-1.5-branch as
e644d2e73f72e7a3e1a9525bdde0de2012efec59.


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.