Subject: Re: [Fwd: FVWM: fvwmaudio & fvwmevent dump cores]

From: "Jacques B. Siboni" <[email-masked]>
Date: Tue, 08 Jun 1999 15:54:20 +0000

Thomas A. Gardiner wrote:
> 
> Jacques,
> 
> I'm having the same problem as you...  Red Hat 5.2 and FvwmAudio core
> dumps do to a seg. fault.  I see that you managed to get the audio working
> by going to version 2.3.3.  Did you have any success using the FvwmEvent
> executeable with version 2.2.2 as Dominik Suggested?
> 
> Thanks,
> 
> Tom Gardiner

Thomas

Yes it is perfect, it works fine ... so far  ...

Jacques

-- 
Dr. Jacques B. Siboni mailto:[email-masked]
8 pass. Charles Albert, F75018 Paris, France
Tel. & Fax: 33 (0) 1 42 28 76 78
Home Page: http://www.lutecium.fr/jacsib/
--
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: "Thomas A. Gardiner" <[email-masked]>
Date: Tue, 8 Jun 1999 12:27:41 -0400 (EDT)

Jacques,

I was wondering if I might ask you just a few more questions regarding how
you got around this problem.  You see I'm trying not to stray too far from
using the Red Hat Package Manager, in hopes to simplify my life in the
future when things (inevitibly) go wrong.  My questions are simple.  I
take it you compiled the recent fvwm2-2.2.2 release. Did you install the
files by hand or did you find the install paths set up properly, allowing
you to just execute the install command?  Did you try using the
FvwmEvent module from version 2.2.2?  You sent around a section of your
.fvwm2rc file, and I assume that is m4 processed output.  Which m4 files
did you choose to modify?  Any thing else you might choose to tell me to
simplify the install??

Thanks,
Tom

Ps.  Sorry for such simple questions, but I'm new to maintaining my own
Linux box...

---

From: Michael Han <[email-masked]>
Date: Tue, 08 Jun 1999 10:58:20 -0700

Previously...
>Yes it is perfect, it works fine ... so far  ...

Jacques, really what you're doing shouldn't be necessary. If I recall
your .fvwm2rc correctly, you're calling FvwmEvent explicitly, not
trying to recycle legacy FvwmAudio config. Try 2.2.2's FvwmEvent.
Hopefully it will work properly with your .fvwm2rc.

Thomas, you had a question about the interaction with the M4 files on
your RedHat system. Take a look at the FVWM FAQ, which addresses this
question.
-- 
[email-masked]
I will not bribe Principal Skinner
 - 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].

---

From: "Jacques B. Siboni" <[email-masked]>
Date: Wed, 09 Jun 1999 07:11:57 +0000

Thomas,

Michael's mail gave the answer. i confirm it works with fvwm2.2.2 event
module. It was actually a configuration problem. The difference between the
2.2.2 and 2.3.3 is that the former dumps core with no explanations when there
is a configuration problem although the latter keeps running.

The result is that now I use the 2.2.2 package as is. So far I did not compile
it as root and did not install it as root, I installed it on my home directory
(using ./configure --prefix=<myhomedir>).

One reason is that I run rpm version 2.0.46, the one provides with RedHat 5.2.
The 2.2.2 was grabbed from fvwm.org

I am using the Nextlevel M4  RedHat package. I have just put the fvwmEvent
instructions in .fvwm2rc.modules here thay are:
######################FvwmEvent###########################################
##### FvwmEvent
#*FvwmEventDir SOUND_DIR
#*FvwmEventCmd SOUND_COMMAND
*FvwmEventCmd myplay
*FvwmEventDelay 0
# User must add a new column to each line below, specifying
# a sound file from SOUND_DIR (define-d in .fvwm2rc-defines)
*FvwmEvent startup 		start.au
*FvwmEvent shutdown 		cannot.be.completed.au
*FvwmEvent unknown 		crash.au
*FvwmEvent add_window 		gong.au
*FvwmEvent raise_window 	door_open.au
*FvwmEvent lower_window 	door_shut.au
#*FvwmEvent focus_change 	long-beep.au
*FvwmEvent focus_change 	thin.bell.au
*FvwmEvent destroy_window 	robot_dead.au
*FvwmEvent iconify 		piano-beep.au
*FvwmEvent deiconify 		meepmeep.au
##*FvwmEvent toggle_paging 	gong.au
*FvwmEvent new_page 		low-smash.au
*FvwmEvent new_desk 		ding.au
#*FvwmEvent configure_window 	drip.au
*FvwmEvent window_name 		metal.au
*FvwmEvent icon_name 		clink.au
*FvwmEvent res_class		chirp1.au
*FvwmEvent res_name		bubble1.au
*FvwmEvent end_windowlist	bass-snap.au

*FvwmEvent error 		cowbell.au
#*FvwmEvent icon_location 	say-beep.au
*FvwmEvent map 			whip.au
*FvwmEvent config_info		ooh.au
*FvwmEvent end_config_info	monkey.au
*FvwmEvent icon_file		return.au
*FvwmEvent default_icon		whistle.au
*FvwmEvent string		jackhammer-short.au
*FvwmEvent mini_icon		hi.au
*FvwmEvent windowshade		hammer.au
*FvwmEvent dewindowshade	cuckoo.au

I put the following lines in .fvwm2rc.init:

AddToFunc "myplay" "I" Exec exec /usr/local/ltcbin/rugplay /usr/share/sound/$0

AddToFunc "SetupFunction"
+ "I" Module FvwmEvent

And I disabled sound events in .fvwm2rc.defines:
# define(`WANT_SOUND_EVENTS')

Cheers

Jacques

---

From: [email-masked]
Date: 09 Jun 1999 13:37:48 +0200

"Thomas A. Gardiner" <[email-masked]> writes:

  > I was wondering if I might ask you just a few more questions
  > regarding how you got around this problem.  You see I'm trying not
  > to stray too far from using the Red Hat Package Manager, in hopes
  > to simplify my life in the future when things (inevitibly) go
  > wrong.  My questions are simple.  I take it you compiled the
  > recent fvwm2-2.2.2 release. Did you install the files by hand or
  > did you find the install paths set up properly, allowing you to
  > just execute the install command?

I think what you should do is to choose a different directory for
installing your own programs.  If you choose one directory per
program, it is very simple to delete the program afterwards.  If you
include the version number in the directory, you can even install two
versions of the same program, try them both, and when you have decided
which one to use, delete the other one.

One of the steps in compiling and installing fvwm is to run the
configure script.  You can just tell it where you want your fvwm to be
installed.  Suppose you decide to install your own software in
/usr/sw, then the following will install fvwm 2.2.3:

        ./configure --prefix=/usr/sw/fvwm/2.2.3 <<other configure args>>
        make
        make install

This will create a directory /usr/sw/fvwm/2.2.3/bin which you need to
add to $PATH: export PATH=/usr/sw/fvwm/2.2.3/bin:$PATH.  Similar for
/usr/sw/fvwm/2.2.3/man and $MANPATH.

That's it!

Installing a new version 2.3.1 is as simple as giving the right
directory name to configure.  Deleting a version is as simple as "rm
-rf /usr/sw/fvwm/2.2.3".

kai
-- 
Abort this operation?   [OK]  [Cancel]

---

From: Graeme McCaffery <[email-masked]>
Date: Wed, 09 Jun 1999 12:48:54 +0000

> which one to use, delete the other one.

this approach works best with a depot program, for example opt_depot. then all
you need is to set the default path to somewhere like /usr/local/bin. the depot
program should then take care of linking the program to the correct locations

Graeme

---

From: "Thomas A. Gardiner" <[email-masked]>
Date: Wed, 9 Jun 1999 13:14:27 -0400 (EDT)

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

I'm going to dig through the FAQ again now for some simple examples of
using FvwmEvent, can anyone think of some which might be indicative of the
problem I'm having?  

Thanks,

---

From: Michael Han <[email-masked]>
Date: Wed, 09 Jun 1999 12:20:47 -0700

Previously...
>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].

---

From: "Jacques B. Siboni" <[email-masked]>
Date: Thu, 10 Jun 1999 06:58:37 +0000

Thomas,

For me it is even stranger, Michael asked me to reproduce the core dump, the
funny thing is that I am not able to reproduce it!!!

When I put back the $1 instead of $0 it just stop working but does not dumps
although I have been bothered with these dumps all the time!!!

What I can say now is "I'm sorry I can't make it stop working!" I suppose I
have been doing something else in between than I can't remember. I am pretty
sure of the configuration files I gave you.

BTW are you sure the play program is on /usr/local/bin and not on /usr/bin in
the Red Hat distribution?

I believe Michael and Dominik are going to be much more helpful than I can be.

Cheers

Jacques

---

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

Previously,

> 5) catch that output and send it to the bug tracking system or to

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

---

From: "Thomas A. Gardiner" <[email-masked]>
Date: Sat, 12 Jun 1999 15:09:51 -0400 (EDT)

Hi All,

I almost managed to get FvwmEvent to play sounds using rplay.  I noticed
the error was directly associated with the line 

so I stripped down the number of FvwmEvent lines to just a few which looks
like this

*FvwmEventCmd builtin-rplay
*FvwmEventRplayHost d185fcdc5.rochester.rr.com
*FvwmEventRplayVolume 127
*FvwmEventDelay 5
*FvwmEvent startup              matra.wav
*FvwmEvent shutdown             Shutdown.wav
*FvwmEvent iconify              shotgun.wav
*FvwmEvent deiconify            Wooeep.wav
*FvwmEvent new_page             Troll_Grumble.wav
*FvwmEvent new_desk             card_shuffle.wav

Picking just a few that I can test.  Now I do not get a core dump, but
still get no sound.  Executing "tail -f ~/.FVWM2-errors" I get the
following output on a RedHat 5.2 system.

[tom@d185fcdc5 tom]$ tail -f .FVWM2-errors 
Window-Ops menu...
Including_fvwm_hostmenus...
Including_defstyles...
Including_modules...
Including forms...
Including_init...
Done
[FVWM][AddToMenu]: <<WARNING>> Hotkey P is reused in menu StartMenu;
second binding ignored.
[FVWM][AddToMenu]: <<WARNING>> Hotkey W is reused in menu Window-Ops;
second binding ignored.
[FVWM][AddToMenu]: <<WARNING>> Hotkey L is reused in menu Window-Ops;
second binding ignored.
rplay: error writing to socket
rplay: error writing to socket
rplay: error writing to socket
rplay: error writing to socket
rplay: error writing to socket
rplay: error writing to socket
rplay: error writing to socket

The errors are occuring when I iconify windows and what-not.  I tried to
specify my hostname as the host to play to, to no avail.  Does anyone out
there have experience with rplay and how I might get around this error?

Thanks,

Tom

Ps. Yes I know I have some hot-keys re-used, I just haven't had a chance
yet to learn how to correct this problem. :-)

---

From: "Thomas A. Gardiner" <[email-masked]>
Date: Sun, 13 Jun 1999 01:02:32 -0400 (EDT)

Hi all,

I finally narrowed down the problem which is causing FvwmEvent and
FvwmTaskBar to core dump.  RedHat 5.2 has defined in the file
fvwm2rc.modules.m4 a list of events under which audio should be played
which are NOT correct.  The two I found which are present are 

*FvwmAudio focus_change_window 
*FvwmAudio toggle_paging

These are not listed for example in the FvwmEvent man page.  Instead,

*FvwmEvent focus_change

is listed in the FvwmEvent man page.  I don't know if something changed
with the core dist of fvwm or whether this problem was always present.
Essentially as I see it, the problem with version 2.2 (I assume from
Jacques' email that it is not present in version 2.3) has to do with how
it should handle the situation when it receives an in-appropriate
definition.  You might try this for yourself, to see if I'm right. :-)
Just change from 

*FvwmEvent focus_change boing.au

to 

*FvwmEvent focus_change_window boing.au

and you should find on restarting fvwm that you get a core dump.  I hope
this serves as a usefull note to other RedHat users.

Cheers,
Tom

Ps. Thanks to all for their help!

---

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