| 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).