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
> fvwm-workers_at_fvwm.org
> --
> mikehan_at_best.com
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_at_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_at_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
> fvwm-workers_at_fvwm.org
> --
> mikehan_at_best.com
> 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 majordomo_at_fvwm.org.
> To report problems, send mail to fvwm-owner_at_fvwm.org.
>
--
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 majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Fri Jun 11 1999 - 18:30:44 BST