Subject: FVWM: Possible bug in LoadPicture()/CachePicture()

From: [email-masked]
Date: Sun, 19 Oct 1997 23:55:23 +0100 (BST)

[I'm new to this list, just subscribed before I sent this, so if this bug is
 known/under discussion, I'm sorry]

fvwm2.0.46 is dumping core on me, running Linux 2.0.31pre10, X11R6.1
(XFree86 3.1).

Active defines in Fvwm.tmpl are

OPTION_DEFINES = -DSHAPE -DVECTOR_BUTTONS -DPIXMAP_BUTTONS -DGRADIENT_BUTTONS -DINACTIVE_BTNS -DMINI_ICONS -DEXTENDED_TITLESTYLE -DWINDOWSHADE

and I have libXpm. fvwm was compiled with gcc 2.7.2.3, both with `-O2 -m486
-mwide-multiply -fomit-frame-pointer -freg-struct-return' and with `-g -m486
-mwide-multiply -freg-struct-return'. The core dump occurs in both cases.

I find it easy to reproduce, but I've only got one system to test it on :(;
including a pixmap in a menu[1], with either % or *, causes a core dump.
Tracing indicates that the system dumps core when loading the pixmap on return
from LoadPicture() to CachePicture() in libs/Display.c. There is no obvious
sign of overwrite errors anywhere in LoadPicture(), other than the fact that
it dumps core on the return (so, presumably, the stack frames have been
mangled. I haven't gdb'ed it yet so can't be sure.)

I've replicated this with both jwindow.xpm and the basic, bare mini.xpm in the
sample pixmaps that come with the fvwm2 distribution.

Either I'm being terribly terribly stupid here, or there is a bug here
somewhere. If anyone wants more info, just ask (I should be subscribed to this
list as this message appears; it may take longer if subscription requires
authentication); the core dump is available if anyone really wants it, but
it's 350K long and I'm on a dialup host :(

[1] i.e. in the AddToMenu label

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

---

From: "Jose' Manuel Pereira" <[email-masked]>
Date: Thu, 23 Oct 1997 19:01:06 +0100

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

---

From: Nix <[email-masked]>
Date: Fri, 24 Oct 1997 03:17:29 +0100 (BST)

>   n> fvwm2.0.46 is dumping core on me, running Linux 2.0.31pre10, X11R6.1
[chop]
> 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... :)

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