Bug 15878

Summary: Using -wm option causes server to SEGV
Product: xorg Reporter: James Cloos <cloos>
Component: Server/GeneralAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium    
Version: git   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 10101    
Attachments:
Description Flags
Xorg log
none
Xorg log file
none
STDERR output from xinit none

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.