On Fri, 1 Feb 2008, Roman S Dubtsov wrote:
Hi,
Thanks a lot for the replies!
First, I have forgot to mention that I run FVWM under gnome-session manager. I
think that this may be important, because sometimes gnome-settings-daemon
resets the wallpaper to the one from gnome settings (I wish I could turn this
off, very annoying). After FVWM crash I still have X up and running and I am
able to restart FVWM from console.
It's definately wallpaper changes that cause the error, and most likely
multiple wallpaper changes in a short time frame. I've not been able to
reporduce it myself yet, and I'm not going to install gnome for this.
Next, I have two separate screens: DFP and TV set up using nvidia proprietary
driver. I have also reproduced the issue using open-source nv dirver, so
screen setup probably is not an issue.
this shouldn't be an issue.
Also, I have attached:
* crash.log.bz2 --- log file obtained after source modifications described in
Viktor's e-mail,
* gdb.log.bz2 --- gdb log,
* fvwm.tar.bz2 --- my config (stripped down a bit).
It seems as if XGetGeometry does the right thing, and gets the size of the
root pixmap, but XGetImage, still generates a BadMatch error. That is
quite strange, since the XServer is grabbed until after the call to
XGetImage. If the pixmap was invalid, I'd think that XGetGeometry should
fail as well, but apparently it doesn't.
[snip]
PS. I have added a check for NULL after XGetImage with a goto to the cleanup
portion of the function and was not able to reproduce the crash.
That's as I expect. THat is actually the best solution I can come up with
right now. But it will not get rid of the X-errors. We should at least add
that kind of checks to all XGetImage calls. But ideally we should also
find a way to not get the error at all. I belive the error will be reduced
if the event queue is checked for additional background changes before
doing any redrawing. That should also save updating root transparancy for
a background that is remeoved directly. It will however not guarantee that
the background pixmap isn't removed during the actual update.
PPS. Just in case, periodically (several minutes after startup, and a day or
two later) I also observe screen lock-ups after dragging a window: window is
not moved, I cannot click on anything, but if there's video output, it goes
on normally. After ~10-15 seconds everything is back to normal.
My guess is hat this is due to the gnome-setting daemon refreshing the
background, as you said it would. Computing the average color of the
background images is somewhat timeconsuming, and fvwm won't do anything
else during that time. If you specify a bg on your RootTransparent
colorsets there should be no averaging, and mostly you will get good
results anyway. (With the exception on when you have many very different
color-wise background images, so you can't select a bg that matches to
them.)
/Viktor
