Subject: FvwmButtons core dump

From: Olivier Chapuis <[email-masked]>
Date: Wed, 15 Aug 2001 08:06:42 +0200

I get a FvwmButtons core dump when I change colorsets and the buttons
contains swallowed shaped app.

FvwmButtons-WMakerApplets: Cause of next X Error.
   Error: 4 (BadPixmap)
   Major opcode of failed request:  54 (FreePixmap)
   Minor opcode of failed request:  0 
   Resource id of failed request:  0x20000a2 
 Leaving a core dump now

[olivier@snoopy bin]$ gdb /usr/local/libexec/fvwm/2.4.1-beta1/FvwmButtons ~/core
GNU gdb 4.18
Core was generated by `/usr/local/libexec/fvwm/2.4.1-beta1/FvwmButtons 19 4 none 0 8 FvwmButtons-WMake'.
Program terminated with signal 6, Abandon.
Reading symbols from /usr/X11R6/lib/libXpm.so.4...done.
Reading symbols from /usr/X11R6/lib/libSM.so.6...done.
Reading symbols from /usr/X11R6/lib/libICE.so.6...done.
Reading symbols from /usr/X11R6/lib/libXext.so.6...done.
Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /usr/lib/gconv/ISO8859-1.so...done.
#0  0x40149091 in kill () from /lib/libc.so.6
(gdb) where
#0  0x40149091 in kill () from /lib/libc.so.6
#1  0x40148d79 in raise () from /lib/libc.so.6
#2  0x4014a4f0 in abort () from /lib/libc.so.6
#3  0x805b97c in error_name (code=134620072) at XError.c:59
#4  0x804b4cd in myErrorHandler (dpy=0x80623a8, event=0xbffff20c)
    at FvwmButtons.c:675
#5  0x4008f66d in _XError () from /usr/X11R6/lib/libX11.so.6
#6  0x4008e16b in _XReply () from /usr/X11R6/lib/libX11.so.6
#7  0x400784c7 in XGetWindowAttributes () from /usr/X11R6/lib/libX11.so.6
#8  0x8059f8f in GetEqualSizeChildren (dpy=0x80623a8, parent=100663299, 
    depth=16, visualid=34, colormap=35, ret_children=0xbffff458)
    at WinMagic.c:268
#9  0x804e04f in change_swallowed_window_colorset (b=0x8077278, do_clear=0)
    at FvwmButtons.c:2325
#10 0x8050a78 in RedrawButton (b=0x8077278, clean=1) at draw.c:350
#11 0x804bdce in Loop () at FvwmButtons.c:1014
#12 0x804bccb in main (argc=7, argv=0xbffff7f4) at FvwmButtons.c:961
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 16 Aug 2001 10:40:46 +0200

> #12 0x804bccb in main (argc=7, argv=0xbffff7f4) at FvwmButtons.c:961

Thiss core dump isn't very helpful.  Obviously an X error occured
that was not handled and then the routine that should generate the
core dump crashed (probably by accessing an array index of
(unsigned char)-1 ).

T'll submit a fix for the crash in XError.c.  Please try to make
that happen again then.  Also, I tried to reproduce this, but
could not.  If the problem does not become obvious with a proper
core dump, can you please provide more information on the bug?

Bye

Dominik ^_^  ^_^

-- 
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Tim Phipps <[email-masked]>
Date: Thu, 16 Aug 2001 10:58:58 +0100

> This core dump isn't very helpful.  Obviously an X error occured

I think the routine worked correctly i.e. it called abort(). The X-error
is included above. Where it originates is another matter, you have to
run in synchronous mode or guess. From the description it sounds like
FvwmButtons is trying to free the shape mask (which belongs to the
swallowed app)

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 16 Aug 2001 11:32:34 +0200

> FvwmButtons is trying to free the shape mask (which belongs to the

No, look closely:  The core dump occured in error_name(), but the
abort() is in PrintXErrorAndCoredump().  The responsible code
looked like this:

  static char *error_name(unsigned char code)
  {
    if (code > (sizeof(error_names) / sizeof(char *)))
      return "Unknown";
    return error_names[code - 1];
  }

So, if the code was ever called with code == 0, it tried to
access error_names[255].  I believe this is what happened.  Of
course the routine should never have been called with a zero
error code in the first place.

Bye

Dominik ^_^  ^_^