>> On Wed, 4 Oct 1995 17:08:27 -0400,
>> Charles Hines(C) wrote:
>>>>>> "mb" == Mark Borges <mdb_at_cdc.noaa.gov> writes:
mb> I built pl36 today, and had two SEGV's in the last couple
mb> hours. So I've gone back to pl35 for now.
C> Bummer.
mb> At the time of the crash, a new window was attempting to be
mb> created. I compiled with SUNWspro cc and -O under Solaris-2.3.
C> What type of window?
It was created by a third-party aplication I've used dozens of times
before with fvwm with no problem. I don't think there is anything
special about it, but xprop/xwininfo info follows nonetheless:
------------------------------------------------------------------------------
$ xprop
WM_STATE(WM_STATE):
window state: Normal
icon window: 0x0
WM_HINTS(WM_HINTS):
Client accepts input or input focus: True
Initial state is Normal State.
bitmap id # to use for icon: 0x4800002
WM_NORMAL_HINTS(WM_SIZE_HINTS):
user specified location: 125, 0
user specified size: 960 by 711
WM_ICON_NAME(STRING) = "ngplot"
WM_NAME(STRING) = "ngplot"
$ xwininfo
xwininfo: Window id: 0x4800001 "ngplot"
Absolute upper-left X: 5
Absolute upper-left Y: 28
Relative upper-left X: 0
Relative upper-left Y: 0
Width: 960
Height: 711
Depth: 8
Visual Class: PseudoColor
Border width: 0
Class: InputOutput
Colormap: 0x21 (installed)
Bit Gravity State: ForgetGravity
Window Gravity State: NorthWestGravity
Backing Store State: Always
Save Under State: no
Map State: IsViewable
Override Redirect State: no
Corners: +5+28 -187+28 -187-161 +5-161
-geometry 960x711+0+0
------------------------------------------------------------------------------
C> Was it for one of the modules (i.e. being swallowed) or was it
C> something else?
No, it was something else. The only thing FvwmButtons swallows is
rclock, like so:
*FvwmButtons(2x2) - whatsit Swallow "Clock" Exec rclock -bg RosyBrown -geometry -1500-1500 -font -*-times-*-r-*-*-17-*-*-*-*-*-*-* -mailupdate 10 &
There is a chance that the window obscured the swallowed rclock
button, and FvwmButtons may have been trying to re-draw it. I'm not
sure.
C> If you can consistently reproduce it, let me know. Also, try
C> compiling w/ debug and getting a traceback off of the core file.
Well, I haven't tried it again, but I just noticed it left a core file
in my home directory (ordinarily these are suppressed by my shell via
`limit core 0', but I guess if the error happens within an xsession
the shell is not involved. Lucky me.)
Anyway, here it is -- it wasn't compiled with w/ debug, but there may
be a grain of clue somewhere:
------------------------------------------------------------------------------
$ dbx ~/misc/bin/X11/fvwm-2p36 core
Reading symbolic information for misc/bin/X11/fvwm-2p36
core file header read successfully
Reading symbolic information for rtld /usr/lib/ld.so.1
Reading symbolic information for /usr/X11R6/lib/libXpm.so.4.6
Reading symbolic information for /usr/X11R6/lib/libXext.so.6.0
Reading symbolic information for /usr/X11R6/lib/libX11.so.6.0
Reading symbolic information for /usr/lib/libsocket.so.1
Reading symbolic information for /usr/lib/libnsl.so.1
Reading symbolic information for /usr/lib/libc.so.1
Reading symbolic information for /usr/lib/libthread.so.1
Reading symbolic information for /usr/lib/libdl.so.1
Reading symbolic information for /usr/lib/libintl.so.1
Reading symbolic information for /usr/lib/libw.so.1
Reading symbolic information for /usr/lib/switch.so
Reading symbolic information for /usr/lib/nss_files.so.1
detected a multithreaded program
(l_at_1) terminated by signal SEGV (no mapping at the fault address)
(dbx) where
=>[1] realfree(0x4e73825c, 0x0, 0x0, 0x433f4, 0x58, 0x4e6f4e61), at 0xef5b96ac
[2] cleanfree(0x0, 0x0, 0xef5f7d04, 0xef5f7d84, 0x0, 0xef5f7d54), at 0xef5b9ecc
[3] _malloc_unlocked(0x10, 0x3b0, 0x61e98, 0x0, 0xfc08352c, 0x1f0), at 0xef5b90b8
[4] malloc(0x10, 0x0, 0x1, 0xa7df5658, 0x1, 0xa7e015c0), at 0xef5b8fb4
[5] safemalloc(0x10, 0x4004667f, 0xeffff204, 0xa7dbf134, 0x0, 0xa7df5658), at 0x314e8
[6] AddToQueue(0x1, 0xeffff23c, 0x24, 0x0, 0x16, 0x16), at 0x2a65c
[7] PositiveWrite(0x1, 0xeffff23c, 0x24, 0x40ddf8bb, 0x61ea0, 0x0), at 0x2a630
[8] Broadcast(0x40, 0x5, 0x0, 0x0, 0x0, 0x0), at 0x2a15c
[9] HandleFocusIn(0x1, 0x43a90, 0x4, 0x46578, 0x80019f, 0x61eb0), at 0x1f748
[10] HandleEvents(0x44ea0, 0x0, 0x0, 0x0, 0x69, 0x15), at 0x1f3c4
[11] main(0x0, 0xeffff81c, 0xeffff82c, 0x43800, 0x0, 0x0), at 0x22668
(dbx) quit
------------------------------------------------------------------------------
Oh, and here's the xdpyinfo output, just in case:
$ xdpyinfo
name of display: hpx06:0.0
version number: 11.0
vendor string: Hewlett-Packard Company
vendor release number: 507000
maximum request size: 262140 bytes
motion buffer size: 100
bitmap unit, bit order, padding: 32, LSBFirst, 32
image byte order: LSBFirst
number of supported pixmap formats: 2
supported pixmap formats:
depth 1, bits_per_pixel 1, scanline_pad 32
depth 8, bits_per_pixel 8, scanline_pad 32
keycode range: minimum 16, maximum 141
focus: window 0x2400002, revert to Parent
number of extensions: 6
HPExtension
HPXTExtension
MIT-SUNDRY-NONSTANDARD
SHAPE
XInputExtension
XTestExtension1
default screen number: 0
number of screens: 1
screen #0:
dimensions: 1152x900 pixels (301x235 millimeters)
resolution: 97x97 dots per inch
depths (2): 1, 8
root window id: 0x24
depth of root window: 8 planes
number of colormaps: minimum 1, maximum 1
default colormap: 0x21
default number of colormap cells: 256
preallocated pixels: black 0, white 1
options: backing-store YES, save-unders YES
largest cursor: unlimited
current input event mask: 0x58003d
KeyPressMask ButtonPressMask ButtonReleaseMask
EnterWindowMask LeaveWindowMask SubstructureNotifyMask
SubstructureRedirectMask PropertyChangeMask
number of visuals: 1
default visual id: 0x22
visual:
visual id: 0x22
class: PseudoColor
depth: 8 planes
available colormap entries: 256
red, green, blue masks: 0x0, 0x0, 0x0
significant bits in color specification: 8 bits
--
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Wed Oct 04 1995 - 17:30:52 BST