Subject: FVWM: Re: fvwm crashes when using dynamic menus

From: Uwe Pross <[email-masked]>
Date: Wed, 24 Jul 2002 14:40:14 +0200

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

Any suggestions?

Uwe
-- 
+----------------------------------------------
| Uwe Pross
| mail : mailto:[email-masked]
| www  : http://www.tu-chemnitz.de/~uwp
+----------------------------------------------

Have a nice day ;-).

-----------------------------------------------

--
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: Dominik Vogt <[email-masked]>
Date: Wed, 24 Jul 2002 15:38:56 +0200

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

> 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: [email-masked], 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 [email-masked].
To report problems, send mail to [email-masked].