> "n" == nix-fvwm <nix-fvwm_at_esperi.demon.co.uk> writes:
>
> n> fvwm2.0.46 is dumping core on me, running Linux 2.0.31pre10, X11R6.1
> n> (XFree86 3.1).
[chop]
>
> 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,
Christ. It didn't do that to me; as I'm not ulimited I think there would
have been a *noticeable* delay while ~100Mb of swap filled up... :)
> Conclusion: seems libxpm is to blame here. Try all visuals in your server in
> turn. Probably some color depths will give trouble.
In the end I narrowed it down; using *anything* which loads pixmaps *at all*
while pixmap support is defined causes the problem. I agree, libXpm is to
blame.
I went for the `when all else fails, recompile everything' approach and moved
to XFree86 3.3.1 (X11R6.3) and libXpm 4.10 (from 4.7) and all now works,
pixmaps appear &c. And it looks utterly, utterly cool. XFree86 3.3.1 is
faster than 3.1 as well, so there are other advantages...
fvwm2 is a remarkable wm, keep up the good work, I'll be using it for a long,
long time!
--
A truly secure computer system can be made by severing it from
all network links, encasing it in concrete and dropping it in mid-
Atlantic. This system's utility is, however, low.
--
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 Fri Oct 24 1997 - 17:19:44 BST