Subject: Re: FVWM: fvwm2.5.5 FvwmTaskbar crashes on resize?

From: [email-masked]
Date: Mon, 3 Mar 2003 00:51:09 +0100

On Sat, Feb 15, 2003 at 09:07:56PM +0100, Gert Brinkmann wrote:
> Olivier Chapuis wrote:
> 
> >No this not normal. Can you your FvwmTaskBar config?
> 
> The bug occurs with a 0 byte (so empty) config, too:
> 
> * Open the "Issue FVWM commands" Console
> * Type "Module FvwmTaskBar"
> * Try to resize the taskbar
> => killed

Doesn't crash here.  Can you post a minimal config file and a
stack trace, please?

  $ gdb FvwmTaskBar core
  (gdb) where

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
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: Gert Brinkmann <[email-masked]>
Date: Sun, 09 Mar 2003 14:01:19 +0100

> Doesn't crash here.  Can you post a minimal config file and a

I could do that but it would make no sense, because the minimal config 
file is an empty config file (so only the fvwm default config is used) 
Do you still want me to post it? :)

>   (gdb) where

I am not sure how to use the gdb. How are the exact steps to make gdb 
what you want? Is it started in the FvwmConsole or in a shell? Perhaps 
gdb did not offer an result because I did install fvwm using 
"checkinstall" and as I remember it strips all executables. I think that 
must not be, am I right?

But i did attach an "strace -p `pidof FvwmTaskBar`". Perhaps this does 
help, too?

And well, I m not sure if FvwmTaskBar really _crashes_. Fact is only 
that the process does not exist anymore after resizing and I see the 
taskbar disappearing. Perhaps it is exited correctly in some why, 
similar as an "-transient" pager?

Gert
select(6, [3 5], NULL, NULL, {26, 430000}) = 1 (in [5], left {26, 30000})
ioctl(3, 0x541b, [0])                   = 0
read(5, "\377\377\377\377", 4)          = 4
read(5, "@\0\0\0\t\0\0\0^\311\321\322", 12) = 12
read(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\367\275\0\0", 20) = 20
time([1047214016])                      = 1047214016
write(3, "=\0\4\0\3\0\340\0\370\0\0\0\261\0\25\0B\0\7\0\3\0\340\0"..., 220) = 220
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
select(6, [3 5], NULL, NULL, {30, 0})   = 1 (in [5], left {29, 340000})
ioctl(3, 0x541b, [0])                   = 0
read(5, "\377\377\377\377", 4)          = 4
read(5, "@\0\0\0\t\0\0\0\374\313\321\322", 12) = 12
read(5, "\3\0\340\0\221\3@\0\0\0\0\0\0\0\0\0\367\275\0\0", 20) = 20
time([1047214017])                      = 1047214017
write(3, "=\0\4\0\3\0\340\0\274\4\0\0006\0\25\0B\0\7\0\3\0\340\0"..., 96) = 96
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
select(6, [3 5], NULL, NULL, {30, 0})   = 1 (in [3], left {29, 140000})
ioctl(3, 0x541b, [32])                  = 0
read(3, "\26\0i\1\3\0\340\0\3\0\340\0\0\0\0\0\0\0\0\0\362\4,\0\0"..., 32) = 32
ioctl(3, 0x541b, [0])                   = 0
write(3, "7\0\7\0\34\0\340\0SHAP\f\0\1\0\1\0\0\0\0\0\0\0\0\0\0\000"..., 200) = 200
read(3, 0xbffffa7c, 32)                 = -1 EAGAIN (Resource temporarily unavailable)
select(4, [3], NULL, NULL, NULL)        = 1 (in [3])
read(3, "\fLi\1\3\0\340\0\0\0\25\0\362\4\27\0\0\0\0\00080[\10P\'"..., 32) = 32
read(3, 0xbffffa7c, 32)                 = -1 EAGAIN (Resource temporarily unavailable)
select(4, [3], NULL, NULL, NULL)        = 1 (in [3])
read(3, "\0\tj\1SHAP\0\0007\10SHAP\0\0\0@\1\0\0\0\2605Y\10\\\375"..., 32) = 32
read(3, "\0\tk\1SHAP\0\0005\10\0\0\0\0pl\0\0\0\0\0\0\0\0\0\0\\\375"..., 32) = 32
read(3, "\0\rl\1\34\0\340\0\0\0008\10\34\0\340\0\3\0\0\200\2\0\0"..., 32) = 32
open("/usr/X11R6/lib/X11/XErrorDB", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=33792, ...}) = 0
brk(0x8091000)                          = 0x8091000
read(4, "! $Xorg: XErrorDB,v 1.3 2000/08/"..., 33792) = 33792
close(4)                                = 0
brk(0x809a000)                          = 0x809a000
brk(0x80a3000)                          = 0x80a3000
brk(0x80a4000)                          = 0x80a4000
brk(0x80a5000)                          = 0x80a5000
brk(0x80a6000)                          = 0x80a6000
brk(0x80a7000)                          = 0x80a7000
brk(0x80a8000)                          = 0x80a8000
brk(0x80a9000)                          = 0x80a9000
write(2, "*FvwmTaskBar: Cause of next X Er"..., 37) = 37
write(2, "   Error: 13 (BadGC (invalid GC "..., 44) = 44
write(2, "   Major opcode of failed reques"..., 50) = 50
write(2, "   Minor opcode of failed reques"..., 39) = 39
write(2, "   Resource id of failed request"..., 45) = 45
write(2, " Leaving a core dump now\n", 25) = 25
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
getpid()                                = 475
kill(475, SIGABRT)                      = 0
--- SIGABRT (Aborted) ---

---

From: Dan Espen <[email-masked]>
Date: Sun, 09 Mar 2003 08:19:35 -0500

Gert Brinkmann <[email-masked]> writes:
> This is a multi-part message in MIME format.
> --------------000201060408080800020102
> Content-Type: text/plain; charset=us-ascii; format=flowed
> Content-Transfer-Encoding: 7bit
> 
> I am not sure how to use the gdb.

I'll explain how to use gdb, but first, here is the stack trace.
(Not very useful.)

(gdb) where
#0  0x40242971 in kill () from /lib/libc.so.6
#1  0x40242775 in raise () from /lib/libc.so.6
#2  0x40243da3 in abort () from /lib/libc.so.6
#3  0x08064827 in PrintXErrorAndCoredump () at ../../fvwm2_5_6/libs/XError.c:81
#4  0x080506b3 in ErrorHandler (d=0x8080208, event=0xbffff550)
    at ../../../fvwm2_5_6/modules/FvwmTaskBar/FvwmTaskBar.c:2500
#5  0x4015d663 in _XError () from /usr/X11R6/lib/libX11.so.6
#6  0x4015c29d in _XReply () from /usr/X11R6/lib/libX11.so.6
#7  0x401579e8 in XSync () from /usr/X11R6/lib/libX11.so.6
#8  0x0804ef7e in LoopOnEvents () at ../../../fvwm2_5_6/modules/FvwmTaskBar/FvwmTaskBar.c:1764
#9  0x0804cb03 in EndLessLoop () at ../../../fvwm2_5_6/modules/FvwmTaskBar/FvwmTaskBar.c:427
#10 0x0804ca0e in main (argc=6, argv=0xbffff8b4)
    at ../../../fvwm2_5_6/modules/FvwmTaskBar/FvwmTaskBar.c:388
#11 0x402305b0 in __libc_start_main () from /lib/libc.so.6

To use gdb with a core file, you need the full path the the executable and
the full path to the core file.  Normally, the core file is in your home
directory.  So:

home> which FvwmTaskBar
/home/dane/bin/fvwm/exec/fvwm/2.5.6/FvwmTaskBar
home> cd
home> gdb /home/dane/bin/fvwm/exec/fvwm/2.5.6/FvwmTaskBar core

then you type "where", then "quit".

Here is the X Error:

*FvwmTaskBar: Cause of next X Error.
   Error: 13 (BadGC (invalid GC parameter))
   Major opcode of failed request:  56 (ChangeGC)
   Minor opcode of failed request:  0 
   Resource id of failed request:  0x4000023 
 Leaving a core dump now

My FvwmTaskBar config:

Style "FvwmTaskBar" NoTitle,BorderWidth 0, HandleWidth 0,Sticky, StaysOnTop, WindowListSkip, CirculateSkip
DestroyModuleConfig FvwmTaskBar
*FvwmTaskBarBack #c3c3c3
*FvwmTaskBarFore black
*FvwmTaskBarTipsBack bisque
*FvwmTaskBarTipsFore black
*FvwmTaskBarGeometry +0-1
*FvwmTaskBarDeskOnly
*FvwmTaskBarFont -adobe-helvetica-medium-r-*-*-14-*-*-*-*-*-*-*
*FvwmTaskBarSelFont -adobe-helvetica-bold-r-*-*-14-*-*-*-*-*-*-*
*FvwmTaskBarStatusFont fixed
*FvwmTaskBarAction Click1 Iconify -1, Raise
*FvwmTaskBarAction Click2 Iconify +1, Lower
*FvwmTaskBarAction Click3 Iconify -1, Raise

#*FvwmTaskBarAutohide
*FvwmTaskBarUseSkipList
*FvwmTaskBarUseIconNames
*FvwmTaskBarAutoStick
*FvwmTaskBarShowTips

*FvwmTaskBarButtonWidth 180
*FvwmTaskBarBellVolume 20
*FvwmTaskBarMailBox /var/spool/mail/
*FvwmTaskBarMailCommand Exec xterm -e mail
*FvwmTaskBarClockFormat %I:%M %p

*FvwmTaskBarStartName Start
*FvwmTaskBarStartMenu StartMenu
*FvwmTaskBarStartIcon mini-exp.xpm

-- 
Dan Espen                           E-mail: [email-masked]

---

From: Gert Brinkmann <[email-masked]>
Date: Sun, 09 Mar 2003 15:02:04 +0100

> To use gdb with a core file, you need the full path the the executable and

Ok, I did not have the core file because "ulimit -c" seems to be set to 
0 by debian woody as default.

> Here is the X Error:

So you do not need my gdb output anymore, right?

> My FvwmTaskBar config:

Does the crash happen on your system with an empty config file, too?

Gert

---

From: Dan Espen <[email-masked]>
Date: Sun, 09 Mar 2003 09:12:10 -0500

> 0 by debian woody as default.

Same on Mandrake.

> So you do not need my gdb output anymore, right?

Right.

> Does the crash happen on your system with an empty config file, too?

Yep.

---

From: [email-masked]
Date: Sun, 9 Mar 2003 23:52:16 +0100

> I'll explain how to use gdb, but first, here is the stack trace.

FYI:  When an X error causes a core dump, add

  XSynchronize(dpy, 1);

right after the initial XOpenDisplay() call.  The dump then occurs
right at the call that is responsible for the X error.

> #11 0x402305b0 in __libc_start_main () from /lib/libc.so.6

Fixed.  Code referenced "colorset" without checking for a valid
value --> &Colorset[-1] --> boom.

Bye

Dominik ^_^  ^_^