--
Schaaf, Jonathan P (GE Healthcare) <jonathan.p.sch...@ge.com> [2013-09-16
21:28:46 +0000]:
>
> I'll keep tinkering with this in my spare time, and I'll see what I can
> figure out.
>
Fwiw, perhaps nothing:
If you have valgrind available, might want to try building fvwm with -g and
then
$ valgrind --leak-check=yes --log-file=/tmp/foo.log \
/usr/bin/fvwm -f ~/.fvwm/config 2> ~/.fvwm/FVWMERRS;
where the second line is whatever you normally use to launch fvwm from your
.xinitrc (or whatever).
The plus side is you'll almost certainly find the problem and get a usable
backtrace if you can tickle it during your normal workflow.
The downside is that valgrind runs the target executable under a synthetic
CPU with something like 25x speed penalty. I've have run fvwm under it though
(on a 7 year old Thinkpad T-43 with 1.8 GHz single-core x86) and while it was
noticeably slow, it was still entirely usable. The caveat is that my fvwm
setup is very simple, and a more complex setup may make it intolerably slow
to use for normal workflow until it fails.
I claim no expertise with valgrind, just a casual user of it, but it has been
been helpful on many occasions. It seems significantly more anal than some
other memory fault diagnosis tools I've tried from time to time, and it's easy
to use, and pretty well documented.
Glenn
