Subject: FvwmEvent Core Dumps

From: "Thomas A. Gardiner" <[email-masked]>
Date: Fri, 11 Jun 1999 19:27:29 -0400 (EDT)

Previously,
   
On Wed, 9 Jun 1999, Michael Han wrote:

> It dumps core with 2.0.46 and with 2.2.2? My first suspicion is to ask
> you what your ModulePath is defined as in .fvwm2rc. Note that the
> behavior of the builtin ModulePath changed between 2.0 and 2.2. It's a
> bit odd that 2.0.46's Event is coring, but maybe there's a third   
> version of Event that's causing trouble... To sum up, make sure that
> you're not trying to run the wrong version of Event, since it makes a
> distinct difference... not necessarily between 2.2 and 2.3, but  
> definitely between 2.0 and 2.2.
>   
> Other than that, you could always do the following:
> 
> 1) Figure out which FvwmEvent you think you're running
> 2) do a 'gdb $fvwmeventpath'
> 3) in gdb, 'core core' (assuming you're in the directory containing
> the FvwmEvent core)
> 4) 'where'
> 5) catch that output and send it to the bug tracking system or to
> [email-masked]
> --
> [email-masked]

Hi,

I haven't given up, and I'd like to thank all of you for your suggestions
and comments.  I have recompiled version 2.2.2 of fvwm and have chose to
build in rplay version 3.2.0b6.  I am using the following command, as per
the man pages

*FvwmEventCmd builtin-rplay

only this time it is not FvwmEvent which core dumps, but FvwmTaskBar.  The
output of running gdb over the core follows.

[tom@d185fcdc5 tom]$ gdb
/home/tom/fvwm2.2.2/libexec/fvwm/2.2.2//FvwmTaskBar
GNU gdb 4.17.0.4 with Linux/x86 hardware watchpoint and FPU support
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
(gdb) core core
Core was generated by `/home/tom/fvwm2.2.2/libexec/fvwm/2.2.2//FvwmTaskBar
9 4 /tmp/fvwmrca28716 0 8'.
Program terminated with signal 11, Segmentation fault.
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/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /lib/libnss_files.so.1...done.
#0  RemoveButton (array=0x8051048, butnum=3) at ButtonArray.c:351
351         temp->next = temp2->next;
(gdb) where
#0  RemoveButton (array=0x8051048, butnum=3) at ButtonArray.c:351
#1  0x804a089 in ProcessMessage (type=128, body=0x8056580) at
FvwmTaskBar.c:371
#2  0x8049e23 in ReadFvwmPipe () at FvwmTaskBar.c:309
#3  0x8049dec in EndLessLoop () at FvwmTaskBar.c:290
#4  0x8049c8f in main (argc=6, argv=0xbffffbd4) at FvwmTaskBar.c:231
(gdb) 

I'm planning on trying to decipher the code this weekend, but I thought I
might ask if anyone out there who probably knows a lot more about this
software than I do would like to help me out?  

The second option I tried was to use another sound player than the
builtin-rplay.  Segments of the fvwm2rc follow

*FvwmEventCmd myplay
*FvwmEventDelay 5
*FvwmEvent startup              matra.wav
*FvwmEvent shutdown             Shutdown.wav

...

AddToFunc "myplay" "I" Exec exec /usr/bin/play /usr/share/sound/$0

AddToFunc "SetupFunction"
+ "I" Exec xpmroot /home/tom/AnotherLevel/XPMs/moorish2.xpm 
#+ "I" Exec xsetroot -solid BG_COLOR
+ "I" Module FvwmEvent 

and 

/usr/bin/play /usr/share/sound/matra.wav 

does play when executed from a shell.

So, again I've run gdb over the core

[tom@d185fcdc5 tom]$ gdb /home/tom/fvwm2.2.2/libexec/fvwm/2.2.2/FvwmEvent 
GNU gdb 4.17.0.4 with Linux/x86 hardware watchpoint and FPU support
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
(gdb) core core
Core was generated by `/home/tom/fvwm2.2.2/libexec/fvwm/2.2.2//FvwmEvent
13 4 /tmp/fvwmrca28862 0 8'.
Program terminated with signal 11, Segmentation fault.
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/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
#0  __strcasecmp (s1=0x0, s2=0x8050ae0 "focus_change_window")
    at ../sysdeps/generic/strcasecmp.c:37
../sysdeps/generic/strcasecmp.c:37: No such file or directory.
(gdb) where
#0  __strcasecmp (s1=0x0, s2=0x8050ae0 "focus_change_window")
    at ../sysdeps/generic/strcasecmp.c:37
#1  0x8049d1d in MatchToken (pstr=0x8050ab0 "focus_change_window",
tok=0x0)
    at Parse.c:202
#2  0x80492a7 in config () at FvwmEvent.c:460
#3  0x8048e7f in main (argc=6, argv=0xbffffbd4) at FvwmEvent.c:251
(gdb) 

This time however I've looked at the file FvwmEvent.c and can only find
one instance of strcasecmp and that is

#ifdef HAVE_RPLAY
    /*
     * Builtin rplay support is enabled when FvwmAudioPlayCmd ==
builtin-rplay.
     */
    if (strcasecmp(cmd_line, "builtin-rplay") == 0)
	if ((rplay_fd = rplay_open(host)) < 0)
	{
	    rplay_perror("rplay_open");
	    exit(1);
	}
#endif

So what gives???

Thanks Much in advance,

Tom

On Wed, 9 Jun 1999, Michael Han wrote:

> Previously...
> >I must be jinxed...  
> >Performing the same chages listed below, and substituting for the sound
> >playing program as 
> >
> >AddToFunc "myplay" "I" Exec exec /usr/local/bin/play /usr/share/sound/$0
> >
> >I've also tried substituting wavplay (the sound files are .wav files) with
> >the same result.
> >
> >I still get a core dump.  What's worse, the FvwmEvent man pages suggest
> >simple examles of using FvwmEvent, like echo-ing a string to the terminal.
> >Even this simple example from the man pages causes a core dump for me.  Is
> >it possible I'm missing something big? or even little...  I should say
> >that I'm trying this with fvwm2.2.046 and fvwm2.2.2
> 
> It dumps core with 2.0.46 and with 2.2.2? My first suspicion is to ask
> you what your ModulePath is defined as in .fvwm2rc. Note that the
> behavior of the builtin ModulePath changed between 2.0 and 2.2. It's a
> bit odd that 2.0.46's Event is coring, but maybe there's a third
> version of Event that's causing trouble... To sum up, make sure that
> you're not trying to run the wrong version of Event, since it makes a
> distinct difference... not necessarily between 2.2 and 2.3, but
> definitely between 2.0 and 2.2.
> 
> Other than that, you could always do the following:
> 
> 1) Figure out which FvwmEvent you think you're running
> 2) do a 'gdb $fvwmeventpath'
> 3) in gdb, 'core core' (assuming you're in the directory containing
> the FvwmEvent core)
> 4) 'where'
> 5) catch that output and send it to the bug tracking system or to
> [email-masked]
> -- 
> [email-masked]
> I will return the seeing-eye dog
>  - The collected wisdom of Bart Simpson
> --
> 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].
> 

--
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: Sun, 13 Jun 1999 05:13:16 +0200

> #4  0x8049c8f in main (argc=6, argv=0xbffffbd4) at FvwmTaskBar.c:231

Try replacing the function RemoveButton in ButtonArray.c (FvwmTaskBar)
with this version (I've checked in a bug fix for 2.3.4, but I think it
works with 2.2.2 too):

void RemoveButton(ButtonArray *array, int butnum)
{
  Button *temp, *temp2;

  if (butnum == 0) {
    temp2 = array->head;
  } else {
    temp = find_n(array, butnum-1);
    if (temp == NULL) return;
    temp2 = temp->next;
  }
  if (temp2 == NULL) return;
  temp->next = temp2->next;

  if (array->tail == temp2) array->tail = temp;

  ButtonDelete(temp2);
  array->count--;
  if (temp != array->head)
    temp = temp->next;
  for (; temp!=NULL; temp=temp->next)
    temp->needsupdate = 1;

  ArrangeButtonArray(array);
}

The reason is that when the last button in the internal list was deleted,
the code tried to access 'temp2->next' although temp2 might be NULL. I didn't
check that fix myself, so it would be nice if you could verify it.

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-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]