Summary: | Using -wm option causes server to SEGV | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | James Cloos <cloos> | ||||||||
Component: | Server/General | Assignee: | 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: |
|
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. Created attachment 16453 [details]
Xorg log file
Created attachment 16454 [details]
STDERR output from xinit
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. 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. ;^) Nominating commit 04211c3532ca078420e3745a5eac3d9de120bc32 for 1.4 and 1.5 branches of xserver. cherry-picked to 1.4 branch. 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.
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).