"n" == nix-fvwm <nix-fvwm_at_esperi.demon.co.uk> writes:
n> [I'm new to this list, just subscribed before I sent this, so if this bug
n> is known/under discussion, I'm sorry]
Not that I have seen.
n> fvwm2.0.46 is dumping core on me, running Linux 2.0.31pre10, X11R6.1
n> (XFree86 3.1).
n> ...
n> I find it easy to reproduce, but I've only got one system to test it on
n> :(; including a pixmap in a menu[1], with either % or *, causes a core
n> dump. Tracing indicates that the system dumps core when loading the
n> pixmap on return from LoadPicture() to CachePicture() in libs/Display.c.
n> There is no obvious sign of overwrite errors anywhere in LoadPicture(),
n> other than the fact that it dumps core on the return (so, presumably, the
n> stack frames have been mangled. I haven't gdb'ed it yet so can't be
n> sure.)
It happened to me while I was testing the new fvwm in Xnest (in a setup
similar to yours). And yes, stack frames were mangled, there was a noticeable
delay while the program filled all stack space! After some .fvwmrc scavenging,
it stopped dumping core, but the loaded pixmaps looked very strange... To cut
a (very) long story short, everything went OK when I ran fvwm *in the main X
server*.
Conclusion: seems libxpm is to blame here. Try all visuals in your server in
turn. Probably some color depths will give trouble.
--
Jose' Pereira
mailto:jmp_at_digitais.ist.utl.pt
Tel. +351.1.841 9340 - Fax. +351.1.841 7499
DEEC - Dep. of Electrical and Computer Engineering
Instituto Superior Tecnico - Technical University of Lisboa
Av. Rovisco Pais - 1096 Lisboa Codex - Portugal
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Thu Oct 23 1997 - 13:01:43 BST