On Wed, Jul 24, 2002 at 02:40:14PM +0200, Uwe Pross wrote:
> On Wed, Jul 24, 2002 at 10:52:21AM +0200, Dominik Vogt wrote:
> >
> > I can't reproduce the problem.
>
> With the new snap shot it takes quite a while and lots of menu
> switches to reproduce the problem.
>
> > Please try to reduce your config as much as possible and find
> > step-by-step instructions.
>
> I tried it by removing the menu style commands and it seemed as if
> were gone. So I applied the styles using FvwmConsole but it did not
> happen again. After using the dynamic menus for a while say more than
> one minute fvwm crashed again.
I'm almost sure that this problem is related to multiple menu
styles. It never happened to me while I was using the default
menu style only, but I could provoke a crash twice when I defined
a new menu style for the root menu.
> I used the line
>
> exec gdb -x ~/gdb_commands /var/tmp/fvwm-test/bin/fvwm >& ~/fvwm_crash.log
>
> in my ~/.xinitrc to obtain a stack trace. Are there any other ways to
> debug fvwm? Maybe one can run fvwm in a virtual X-server. This would
> be nice since finding the cause of this crash would not kill all
> other x-applications, which is quite annoying.
You can run a separate X server or an Xnest in a window.
In case you have XFree, to run a separate X server, issue these
commands from an xterm:
$ xinit /bin/sleep 100000 -- :1
(XFree switches to new server)
(hit ctrl-alt-f7 to return to :0)
$ fvwm2 -d :1 ...
(switch to other X server with ctrl-alt-fn)
To run fvwm in an Xnest window (Xnest should run on any X server):
$ Xnest -full -sync -name "Xnest :3" -fp `xset -q | grep fonts` :3
$ fvwm2 -d :3 ...
Both ways have their disadvantages. With a separate X server,
XFree frequently hangs when switching displays, especially if the
pointer/keyboard/server is grabbed. Xnest does not handle all
types of events well. It's especially annoying that you can't
easily leave the Xnest window without moving the pointer across
it. You could use the WarpPointer command for that. Also, key
bindings don't work in an Xnest window if they are already handled
by the parent fvwm. Furthermore it is sometimes difficult to
attach a debugger to an fvwm running under Xnest.
However, the biggest problem at hand is to reproduce the problem
at will. As long as it happens at a random time in a function
that just accesses memory that was corrupted somewhere else, the
core dumps are not very helpful.
Maybe someone can run Purify or insure++ once we find a fairly
reliable way to trigger the memory corruption.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, mail: dominik.vogt_at_schlund.de, phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
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 Wed Jul 24 2002 - 08:40:22 BST