The subject pretty much defines the problem.
After enabling per-process setid core dumps, I got a stack trace:
# pstack core
core 'core' of 25655: /usr/openwin/bin/Xsun :0 -nobanner -audiobell
/dev/audio -dev /dev/fb
001038dc damageDamageRegion (42ecc4, ffbfec14, 1, 0, 487360, 411c00) + 90
00103cd0 damageDamageBox (42ecc4, ffbfec80, 6400000, 305, 0, 402400) + 74
00106338 damagePolySegment (42ecc4, 4882a8, 8, 10f4230, 2f3, 2f30000) + 4b0
000db340 ProcAllPlanesPolySegment (1bd550, 9667d8, 0, 10f4230, 8, 42ecc4) + 510
0003fb6c Dispatch (0, ffbfed68, 0, 41162c, 1bb820, 1bb82c) + 1d0
00062998 main (1bcc00, 411538, 4, 1bbb74, 411400, 1) + 8d4
00071850 _start (0, 0, 0, 0, 0, 0) + 108
# pldd core
core 'core' of 25655: /usr/openwin/bin/Xsun :0 -nobanner -audiobell
/dev/audio -dev /dev/fb
/lib/libc.so.1
/usr/openwin/server/lib/libmpg.so.1
/usr/openwin/platform/sun4u/server/lib/libmpg_psr.so.1
/usr/openwin/server/lib/libovl.so.1
/usr/openwin/server/lib/libmi.so.1
/usr/openwin/server/lib/libxinput.so.1
/lib/libsocket.so.1
/usr/openwin/server/lib/libfont.so.1
/usr/openwin/server/lib/libtypesclr.so.0
/usr/openwin/server/lib/libmhc.so.1
/usr/openwin/lib/libowconfig.so.0
/usr/openwin/server/lib/libcfb.so.1
/usr/openwin/server/lib/libcfb4.so.1
/usr/openwin/server/lib/libcfb16.so.1
/usr/openwin/server/lib/libcfb32.so.1
/usr/openwin/server/lib/libmfb.so.1
/lib/libnsl.so.1
/platform/sun4u-us3/lib/libc_psr.so.1
/usr/X11/lib/libXdmcp.so.6
/usr/openwin/server/modules/ddxSUNWgfb.so.1
/lib/libm.so.2
/usr/openwin/server/lib/libserverdps.so.5
/usr/openwin/server/lib/libfb.so.1
/usr/X11/lib/libXau.so.6
/lib/libz.so.1
/usr/lib/libproject.so.1
/usr/openwin/server/modules/SUNWXtsol.so.1
/usr/openwin/server/modules/ddxSUNWkbd.so.1
/usr/openwin/server/modules/ddxSUNWmouse.so.1
/lib/libsecdb.so.1
/lib/libproc.so.1
/lib/librt.so.1
Doesn't seem to matter what the window is (firefox, dtterm, whatever).
Maximize,
normalize, minimize, restore all work fine. Nor does it matter whether the
window is
resized using the mouse to drag the border, or using the window menu and arrow
keys.
Oddly, this does _not_ happen using the GNOME desktop. I don't recall whether
or
not I resized any windows during install, so I don't know if the problem was
also present
under the circumstances applicable then (install used dtwm, but a lot less than
a full
CDE session environment).
Frame buffer info:
# fbconfig -prconf
--- Hardware Configuration for /dev/fb (gfb0) ---
Type: Sun XVR-1000 Graphics Accelerator
Part: 501-5865
Memory:
MAJC: 32MB
Texture: 256MB total
3DRAM64: 5.0M pixels
Versions: FCode 1.15 MCode 0.19 MAJC 2.1 FBC3 3.0 XChip 2.0
Power Level:
Monitor Power: On
Board Power: On
Video Streams:
Stream a
Current resolution Setting: UNINITIALIZED
Flags: None
Monitor/EDID data (13W3)
EDID Data: Not Available
Stream b
Current resolution Setting: VESA_STD_1600x1200x75
Flags: Allocated Console Default Primary
Monitor/EDID data (HD15)
Monitor Manufacturer: SYL
EDID: Version 1, Revision 3
Monitor/EDID data (DVI)
Other info:
# uname -a
SunOS paradox 5.11 snv_90 sun4u sparc SUNW,Sun-Blade-1000
(actually a 2000, which normally reports as a 1000)
# pargs core
core 'core' of 25655: /usr/openwin/bin/Xsun :0 -nobanner -audiobell
/dev/audio -dev /dev/fb defclass
argv[0]: /usr/openwin/bin/Xsun
argv[1]: :0
argv[2]: -nobanner
argv[3]: -audiobell
argv[4]: /dev/audio
argv[5]: -dev
argv[6]: /dev/fb
argv[7]: defclass
argv[8]: TrueColor
argv[9]: defdepth
argv[10]: 24
argv[11]: -dpi
argv[12]: 72
argv[13]: +xrender
argv[14]: -auth
argv[15]: /var/dt/A:0-NaaqKW
(+xrender doesn't apply to the frame buffer driver, but never hurt anything
back on snv_81)
Anything else useful I can dig out of the core file, let me know. This is
_seriously_annoying_.
A more paranoid person might suspect this was meant to strongly encourage
people to hurry
up and start using GNOME instead of CDE. :-) But in any case, it's not good
having
clients so easily able to cause the X server to SEGV.
This message posted from opensolaris.org
