Subject: FVWM: 2.0pl36 not ready for prime time

From: Mark Borges <[email-masked]>
Date: Wed, 4 Oct 1995 14:26:34 -0600

I built pl36 today, and had two SEGV's in the last couple hours. So
I've gone back to pl35 for now.

I'm not exactly sure what is triggering the problem. Here's the
contents of my xsessionlog:

------------------------------------------------------------------------------
14975 Segmentation Fault - core dumped
X connection to hpx06:0.0 broken (explicit kill or server shutdown).
------------------------------------------------------------------------------

and the X terminal reports a fatal I/O error (broken pipe) or
somesuch.

The only modules I use are FvwmPager and FvwmButtons. Were any changes
made in these w.r.t. pl35? Is it possible for a module to cause fvwm
to crash, or is the problem necessarily in fvwm itself?

At the time of the crash, a new window was attempting to be
created. I compiled with SUNWspro cc and -O under Solaris-2.3.

I know, not much help. I'll try to provide more info when I have some
free time over the weekend.

  -mb-

--
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: <[email-masked]> (Charles Hines)
Date: Wed, 4 Oct 1995 17:08:27 -0400

>>>>> "mb" == Mark Borges <[email-masked]> 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.

Bummer.

mb> I'm not exactly sure what is triggering the problem. Here's the
mb> contents of my xsessionlog:

mb> ------------------------------------------------------------------------------
mb> 14975 Segmentation Fault - core dumped
mb> X connection to hpx06:0.0 broken (explicit kill or server shutdown).
mb> ------------------------------------------------------------------------------

mb> and the X terminal reports a fatal I/O error (broken pipe) or
mb> somesuch.

mb> The only modules I use are FvwmPager and FvwmButtons. Were any
mb> changes made in these w.r.t. pl35?

I made a change to FvwmButtons to prevent it from doing nasty things
to the X server if you killed it and it had swallowed modules in
there, but that's about it.

mb> Is it possible for a module to cause fvwm to crash, or is the
mb> problem necessarily in fvwm itself?

I don't think that a module can really crash fvwm, since they only do
socket communication and are actually to separate processes.  But
module communication could trigger a bug in fvwm.

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.

What type of window?  Was it for one of the modules (i.e. being
swallowed) or was it something else?

mb> I know, not much help. I'll try to provide more info when I have
mb> some free time over the weekend.

If you can consistently reproduce it, let me know.  Also, try
compiling w/ debug and getting a traceback off of the core file.

Chuck

*******************************************************************************
Charles K. Hines
IBM Logic Synthesis developer [BooleDozer (TM)]
and Martial Arts Instructor [Modern Arnis, Presas Style Filipino Martial Arts]

Internet e-mail:     [email-masked]

IBM Internal e-mail: [email-masked]   (preferred from workstation)
                     HINESC at FISHKILL       (preferred from mainframe)
                     HINESC at FSHVMFK1       (discouraged, but I'll get it)

*******************************************************************************
 "dis ting could have possabiwities if I put my twisted widdle mind to it!"
                                                        - Bugs Bunny

 "I have a paper plate in my head because they were all out of the metal ones"
                                                        - Rick Overton
*******************************************************************************
--
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Mark Borges <[email-masked]>
Date: Wed, 4 Oct 1995 16:34:29 -0600

>> On Wed, 4 Oct 1995 17:08:27 -0400,
>> Charles Hines(C) wrote:

C> Bummer.

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@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 [email-masked].
To report problems, send mail to [email-masked].

---

From: Mark Borges <[email-masked]>
Date: Thu, 5 Oct 1995 10:41:00 -0600

>> On Wed, 04 Oct 1995 16:34:29 -0600,
>> Mark Borges(mb) wrote:

C> Bummer.

mb> Well, I haven't tried it again, but I just noticed it left a core file
mb> in my home directory ...it wasn't compiled with w/ debug, but there may

This one was.

This was the error in my xsession log file:

12096 Segmentation Fault - core dumped
X connection to hpx06:0.0 broken (explicit kill or server shutdown).

and here's a traceback:

------------------------------------------------------------------------------
$ dbx ~/misc/bin/X11/fvwm-2p36g core
Reading symbolic information for misc/bin/X11/fvwm-2p36g
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@1) terminated by signal SEGV (no mapping at the fault address)
Current function is AddWindow
  107     tmp_win = (FvwmWindow *)calloc(1, sizeof(FvwmWindow));
(dbx) list 
  107     tmp_win = (FvwmWindow *)calloc(1, sizeof(FvwmWindow));
  108     if (tmp_win == (FvwmWindow *)0)
  109       {
  110         return NULL;
  111       }
  112     tmp_win->flags = 0;
  113     tmp_win->w = w;
  114   
  115     tmp_win->cmap_windows = (Window *)NULL;
  116   
(dbx) where
  [1] realfree(0x4e756124, 0x0, 0x0, 0x612bc, 0x1f0, 0x4e6f4e61), at 0xef5b96ac
  [2] cleanfree(0x0, 0x0, 0xef5f7d04, 0xef5f7d84, 0x0, 0xef5f7d54), at 0xef5b9ecc
  [3] _malloc_unlocked(0x1f0, 0x3c00001, 0x79490, 0x5724866c, 0x0, 0x10), at 0xef5b90b8
  [4] malloc(0x1f0, 0x1, 0x1f0, 0xffffffff, 0xffffffff, 0x1), at 0xef5b8fb4
  [5] calloc(0x1, 0x1f0, 0x6ea20, 0x5722f414, 0x0, 0x1f0), at 0xef5acdc0
=>[6] AddWindow(w = 62914561), line 107 in "/tmp/mdb/fvwm/fvwm/add_window.c"
  [7] HandleMapRequest(KeepRaised = 0), line 630 in "/tmp/mdb/fvwm/fvwm/events.c"
  [8] DispatchEvent(), line 115 in "/tmp/mdb/fvwm/fvwm/events.c"
  [9] HandleEvents(), line 178 in "/tmp/mdb/fvwm/fvwm/events.c"
  [10] main(argc = 3, argv = 0xeffff81c), line 402 in "/tmp/mdb/fvwm/fvwm/fvwm.c"
(dbx) 
------------------------------------------------------------------------------
--
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Mark Borges <[email-masked]>
Date: Thu, 5 Oct 1995 10:58:32 -0600

C> Bummer.

This SEGV occurs in AddWindow(), and appears to be related to this
change:

pl 35 to 36
       6. Reverting NoClass patch completely, as I think it's causing
          other problems

Perhaps it wasn't backed out completely?

Also, I hadn't noticed the other problems present in pl35. Can you
elaborate please?

  -mb-

---

From: <[email-masked]> (Charles Hines)
Date: Thu, 5 Oct 1995 14:02:51 -0400

C> Bummer.

mb> This SEGV occurs in AddWindow(), and appears to be related to this
mb> change:

mb> pl 35 to 36
mb>        6. Reverting NoClass patch completely, as I think it's causing
mb>           other problems

mb> Perhaps it wasn't backed out completely?

Ah!  I remember now...  That is correct - I hadn't finished backing it
all the way out and got sidetracked by something else.  I'm finishing
it up right now, and I'll hopefully have a patch for you shortly.

mb> Also, I hadn't noticed the other problems present in pl35. Can you
mb> elaborate please?

I don't remember exactly what "other problems" was concerned about at
the time.  Sorry.  But it did mess up the way the FvwmIconBox worked,
and potentially other modules (window list?), so that was the primary
motivator for attempting to back it out.  BTW - Rob hadn't tested it
at all when it was given to him, he just included it and he told me
that when he gave me pl34.

Also, I'm not certain what the advantage of not re-naming or
re-classing no name & no class windows is while I can see advantages
to giving them a name/class that shows that they didn't have one
originally.

Chuck