Subject: Re: xsrc/15357: stack trashing bug crashing the sparc Xservers
To: NetBSD GNATS submissions and followups <gnats-bugs@gnats.netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: netbsd-bugs
Date: 02/06/2002 19:16:47
I finally managed to generate one apparently good Xserver core dump with
a completely coherent stack and seemingly one bad pointer in one data
structure:
$ gdb XsunMono ~/XsunMono-sigsegv-good-stack.3.core
GNU gdb 4.17
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc--netbsd"...
Core was generated by `XsunMono'.
Program terminated with signal 11, Segmentation fault.
#0 0xc58cc in mfbDestroyPixmap (pPixmap=0x9fc30000) at mfbpixmap.c:110
110 if(--pPixmap->refcnt)
(gdb) where
#0 0xc58cc in mfbDestroyPixmap (pPixmap=0x9fc30000) at mfbpixmap.c:110
#1 0x11fc28 in miDestroyBSPixmap (pWin=0x37ee00) at mibstore.c:3595
#2 0x11db1c in miBSFree (pWin=0x37ee00) at mibstore.c:2606
#3 0x118644 in miBSChangeWindowAttributes (pWin=0x37ee00, mask=64)
at mibstore.c:674
#4 0x114da0 in miPostChangeSaveUnder (pWin=0x451100, pFirst=0x39ca00)
at miwindow.c:325
#5 0x3fc04 in UnmapWindow (pWin=0x451100, fromConfigure=0) at window.c:3045
#6 0x52344 in ProcUnmapWindow (client=0x380900) at dispatch.c:568
#7 0x51934 in Dispatch () at dispatch.c:300
#8 0x2c37c in main (argc=6, argv=0xeffff30c) at main.c:400
#9 0x10238 in ___start ()
(gdb) print *pPixmap
Cannot access memory at address 0x9fc30000.
(gdb) up
#1 0x11fc28 in miDestroyBSPixmap (pWin=0x37ee00) at mibstore.c:3595
3595 (* pScreen->DestroyPixmap)(pBackingStore->pBackingPixmap);
(gdb) print *pBackingStore
$2 = {pBackingPixmap = 0x9fc30000, x = 256, y = 0, SavedRegion = {extents = {
x1 = 4287, y1 = -94, x2 = 256, y2 = 0}, data = 0xa404a001},
viewable = 16 '\020', status = -65 '\277', backgroundState = -1 '\377',
background = {pixmap = 0x1000000, pixel = 16777216}}
(gdb) list
3590 ScreenPtr pScreen;
3591
3592 pScreen = pWin->drawable.pScreen;
3593 pBackingStore = (miBSWindowPtr) pWin->backStorage;
3594 if (pBackingStore->pBackingPixmap)
3595 (* pScreen->DestroyPixmap)(pBackingStore->pBackingPixmap);
3596 pBackingStore->pBackingPixmap = NullPixmap;
3597 pBackingStore->x = 0;
3598 pBackingStore->y = 0;
3599 if (pBackingStore->backgroundState == BackgroundPixmap)
(gdb) print *pWin
$3 = {drawable = {type = 0 '\000', class = 1 '\001', depth = 1 '\001',
bitsPerPixel = 1 '\001', id = 33554892, x = 6, y = 147, width = 150,
height = 24, pScreen = 0x361600, serialNumber = 26343}, parent = 0x46ac00,
nextSib = 0x4c2a00, prevSib = 0x4c7200, firstChild = 0x37ef00,
lastChild = 0x37ef00, clipList = {extents = {x1 = 0, y1 = 0, x2 = 0,
y2 = 0}, data = 0x318c50}, borderClip = {extents = {x1 = 64, y1 = 4226,
x2 = 5, y2 = 22124}, data = 0x4727e0}, valdata = 0xefffee6c, winSize = {
extents = {x1 = -4097, y1 = -4424, x2 = 0, y2 = 0}, data = 0x0},
borderSize = {extents = {x1 = -1, y1 = -1, x2 = 56, y2 = 2304},
data = 0x389cc0}, origin = {x = 0, y = 0}, borderWidth = 0,
deliverableEvents = 0, eventMask = 452672, background = {pixmap = 0x108d28,
pixel = 1084712}, border = {pixmap = 0xefffeee8, pixel = 4026527464},
backStorage = 0x6f1f4, optional = 0x4c5240, backgroundState = 2,
borderIsPixel = 1, cursorIsNone = 0, backingStore = 0, saveUnder = 0,
DIXsaveUnder = 0, bitGravity = 0, winGravity = 1, overrideRedirect = 0,
visibility = 3, mapped = 1, realized = 0, viewable = 0, dontPropagate = 0,
forcedBS = 0, devPrivates = 0x37ee84}
(gdb)
Damned if I know whether this is related to the stack-smash bug, or not,
but it did happen in the same kind of way -- I was just positioning the
cursor to wait for a new xterm to open when it went boom. IIRC the
window manager had not yet drawn the new window outline.... The server
hadn't been running for very long at all.
I've looked up and down through all the stack frames and everything
looks like it holds together properly. I don't see any other values
obviously related to the trashed pBackingPixmap pointer's value, but
there's a lot of data to look through and I don't have a clue where to
start....
--
Greg A. Woods
+1 416 218-0098; <gwoods@acm.org>; <g.a.woods@ieee.org>; <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>