Re: FVWM: SIGSEGV in colorset.c
Hi,
On Monday 04 February 2008, Dominik Vogt wrote:
Should be fixed with my latest commit. I think the X error should
be gone too. Can you try it and look if the X error reappears,
pease?
I have attached a patch which checks image != NULL before calling
XDestroyImage(image). After this, FVWM does not crash, but my
FvwmButtons-based panel does (see log attached).
--
Regards,
Roman
Index: fvwm/colorset.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/colorset.c,v
retrieving revision 1.55
diff -u -p -r1.55 colorset.c
--- fvwm/colorset.c 3 Feb 2008 23:12:19 - 1.55
+++ fvwm/colorset.c 4 Feb 2008 16:15:32 -
@@ -1191,7 +1191,10 @@ void parse_colorset(int n, char *line)
ERR, parse_colorset,
error reading root background);
}
- XDestroyImage(image);
+ if (image != None)
+ {
+XDestroyImage(image);
+ }
if (mask_image != None)
{
XDestroyImage(mask_image);
GNU gdb 6.7.1-debian
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as i486-linux-gnu...
Using host libthread_db library /lib/i686/cmov/libthread_db.so.1.
(gdb) run
Starting program: /home/busa/apps/fvwm-cvs/bin/fvwm --replace
[Thread debugging using libthread_db enabled]
/bin/sh: sh -c 'find /home/busa/.fvwm/var -type f -print0 | xargs -0 rm': No such file or directory
[fvwm.1][ReadDecorFace]: ERROR unknown button face flag 'Raised,' -- line: -- Raised, HiddenHandles
/bin/sh: sh -c 'find /home/busa/.fvwm/var -type f -print0 | xargs -0 rm': No such file or directory
[fvwm.0][parse_colorset]: ERROR error reading root background
[fvwm.1][CMD_EdgeResistance]: DEPRECATED The command EdgeResistance with three arguments is obsolete. Please use the following commands instead:
[fvwm.1][]: DEPRECATED EdgeResistance 1000
[fvwm.1][]: DEPRECATED Style * EdgeMoveDelay 1000
[fvwm.1][]: DEPRECATED Style * EdgeMoveResistance 20
[fvwm.1][CMD_SnapGrid]: DEPRECATED The command SnapGrid is obsolete. Please use the following command instead:
[fvwm.1][]: DEPRECATED Style * SnapGrid 5 5
[fvwm.1][CMD_SnapAttraction]: DEPRECATED The command SnapAttraction is obsolete. Please use the following command instead:
[fvwm.1][]: DEPRECATED Style * SnapAttraction 5
[fvwm.0][parse_colorset]: ERROR error reading root background
[fvwm.0][ReadDecorFace]: ERROR unknown button face flag 'Raised,' -- line: -- Raised, HiddenHandles
[fvwm.0][CMD_EdgeResistance]: DEPRECATED The command EdgeResistance with three arguments is obsolete. Please use the following commands instead:
[fvwm.0][]: DEPRECATED EdgeResistance 1000
[fvwm.0][]: DEPRECATED Style * EdgeMoveDelay 1000
[fvwm.0][]: DEPRECATED Style * EdgeMoveResistance 20
[fvwm.0][CMD_SnapGrid]: DEPRECATED The command SnapGrid is obsolete. Please use the following command instead:
[fvwm.0][]: DEPRECATED Style * SnapGrid 5 5
[fvwm.0][CMD_SnapAttraction]: DEPRECATED The command SnapAttraction is obsolete. Please use the following command instead:
[fvwm.0][]: DEPRECATED Style * SnapAttraction 5
[fvwm.1][Echo]: 32
[fvwm.1][Echo]: 0
[fvwm.1][Echo]: 0
[fvwm.1][Echo]: 0
[fvwm.1][parse_colorset]: ERROR error reading root background
[fvwm.1][parse_colorset]: ERROR error reading root background
[fvwm.0][Echo]: 32
[fvwm.0][Echo]: 0
[fvwm.0][Echo]: 0
[fvwm.0][Echo]: 0
[fvwm.0][parse_colorset]: ERROR error reading root background
[fvwm.0][parse_colorset]: ERROR error reading root background
[fvwm.0][FvwmErrorHandler]: ERROR *** internal error ***
[fvwm.0][FvwmErrorHandler]: ERROR Request 73, Error 8, EventType: 28
[fvwm.0][parse_colorset]: ERROR error reading root background
[fvwm.0][FvwmErrorHandler]: ERROR *** internal error ***
[fvwm.0][FvwmErrorHandler]: ERROR Request 73, Error 8, EventType: 28
[fvwm.0][parse_colorset]: ERROR error reading root background
ComboPanel: Cause of next X Error.
Error: 13 (BadGC (invalid GC parameter))
Major opcode of failed request: 70 (PolyFillRectangle)
Minor opcode of failed request: 0
Resource id of failed request: 0x320
[fvwm.0][parse_colorset]: ERROR error reading root background
[fvwm.0][parse_colorset]: ERROR error reading root background
[fvwm.1][parse_colorset]: ERROR error reading root background
[fvwm.1][parse_colorset]: ERROR error reading root background
Re: FVWM: SIGSEGV in colorset.c
On Mon, Feb 04, 2008 at 10:30:03PM +0600, Roman S Dubtsov wrote: On Monday 04 February 2008, Dominik Vogt wrote: Should be fixed with my latest commit. I think the X error should be gone too. Can you try it and look if the X error reappears, pease? I have attached a patch which checks image != NULL before calling XDestroyImage(image). After this, FVWM does not crash, I've applied the patch. but my FvwmButtons-based panel does (see log attached). There is no output of FvwmButtons in there. Can you please post a stack trace in a new thread please? [snip] [fvwm.1][parse_colorset]: ERROR error reading root background [fvwm.1][parse_colorset]: ERROR error reading root background [snip] [fvwm.0][parse_colorset]: ERROR error reading root background [fvwm.0][parse_colorset]: ERROR error reading root background [fvwm.0][FvwmErrorHandler]: ERROR *** internal error *** [fvwm.0][FvwmErrorHandler]: ERROR Request 73, Error 8, EventType: 28 [fvwm.0][parse_colorset]: ERROR error reading root background [fvwm.0][FvwmErrorHandler]: ERROR *** internal error *** [fvwm.0][FvwmErrorHandler]: ERROR Request 73, Error 8, EventType: 28 [fvwm.0][parse_colorset]: ERROR error reading root background [snip] [fvwm.0][parse_colorset]: ERROR error reading root background [fvwm.0][parse_colorset]: ERROR error reading root background [fvwm.1][parse_colorset]: ERROR error reading root background [fvwm.1][parse_colorset]: ERROR error reading root background Oh my, you seem to get *tons* of these errors. It looks like some process updates the root backgorund and then immediately changes it quite often. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: SIGSEGV in colorset.c
On Tuesday 05 February 2008, Dominik Vogt wrote: [snip] There is no output of FvwmButtons in there. Can you please post a stack trace in a new thread please? Log file has these lines that are related to FvwmButtons (starting from line 52): ComboPanel: Cause of next X Error. Error: 13 (BadGC (invalid GC parameter)) Major opcode of failed request: 70 (PolyFillRectangle) Minor opcode of failed request: 0 Resource id of failed request: 0x320 I doubt I will be able to post a stack trace since FvwmButtons did not dump core, they just exited due to some error condition. (The message above looks like it is from default X11 error handler which exists after printing a error AFAIK). Could you please hint me how to obtain log file solely from FvwmButtons? Regards, Roman
Re: FVWM: SIGSEGV in colorset.c
On Tue, Feb 05, 2008 at 03:00:18AM +0600, Roman S Dubtsov wrote: On Tuesday 05 February 2008, Dominik Vogt wrote: [snip] There is no output of FvwmButtons in there. Can you please post a stack trace in a new thread please? Log file has these lines that are related to FvwmButtons (starting from line 52): ComboPanel: Cause of next X Error. Error: 13 (BadGC (invalid GC parameter)) Major opcode of failed request: 70 (PolyFillRectangle) Minor opcode of failed request: 0 Resource id of failed request: 0x320 I doubt I will be able to post a stack trace since FvwmButtons did not dump core, they just exited due to some error condition. (The message above looks like it is from default X11 error handler which exists after printing a error AFAIK). Could you please hint me how to obtain log file solely from FvwmButtons? You can't. Most of the modules, including FvwmButtons, do not print much to the console. FvwmButtons should really write a core file here as it crashes with abort(). I have committed a patch that tries to force a core by accessing a null pointer instead. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: SIGSEGV in colorset.c
On Tue, 5 Feb 2008, Dominik Vogt wrote: On Tue, Feb 05, 2008 at 03:00:18AM +0600, Roman S Dubtsov wrote: On Tuesday 05 February 2008, Dominik Vogt wrote: [snip] There is no output of FvwmButtons in there. Can you please post a stack trace in a new thread please? Log file has these lines that are related to FvwmButtons (starting from line 52): ComboPanel: Cause of next X Error. Error: 13 (BadGC (invalid GC parameter)) Major opcode of failed request: 70 (PolyFillRectangle) Minor opcode of failed request: 0 Resource id of failed request: 0x320 I doubt I will be able to post a stack trace since FvwmButtons did not dump core, they just exited due to some error condition. (The message above looks like it is from default X11 error handler which exists after printing a error AFAIK). Could you please hint me how to obtain log file solely from FvwmButtons? You can't. Most of the modules, including FvwmButtons, do not print much to the console. FvwmButtons should really write a core file here as it crashes with abort(). I have committed a patch that tries to force a core by accessing a null pointer instead. Actually you could write up a script that lies inbetween fvwm and the modules to do some redirection of output. But since the modules mostly don't generate any output that wouldn't be of mush help. However it is fully possible to attach a gdb process to any running module do do live debugging. The attached script starts a module and then opens an xterm with gdb attached to that module. It should be put into the module path and then used as DebugModule FvwmModule module arguments /Viktor#!/bin/sh i=1 args= while [ $i -lt 6 ] do args=$args $1 i=`expr $i + 1` shift done title=gdb: $1 module=$1 shift which=`which which` module=`env PATH=$FVWM_MODULEDIR $which $module` $module $args $@ module_pid=$! xterm -T $title -e gdb $module $module_pid
Re: FVWM: SIGSEGV in colorset.c
On Saturday 02 February 2008, Viktor Griph wrote: On Sat, 2 Feb 2008, Roman S Dubtsov wrote: On Saturday 02 February 2008, Viktor Griph wrote: ...snip... 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.) Thanks! I'll try. Somehow, I was thinking that it is impossible to specify bg with RootTransparent. Just remember to remove the bg if we ask you to try to reproduce the bug again. It won't happen without bg-averaging. /Viktor Just a quick note: 1. Intermittent hangs were not related to this issue, it was because I started my tray app without 'Exec exec' and fvwm was handing in FvwmFlushMessageQueue() (in select() call from FvwmSelect(), actually). Did not debug it thoroughly, but it seems that fvwm thought that tray was a module and tried to post messages to its stdin. 2. To disable GNOME background it is required to set /desktop/gnome/background/draw_background to false in gconf. -- Regards, Roman
Re: FVWM: SIGSEGV in colorset.c
On Fri, Feb 01, 2008 at 08:53:32PM +0100, Viktor Griph wrote: On Fri, 1 Feb 2008, Roman S Dubtsov wrote: [snip] 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. That's because it is necessary to call XSync() right after grabbing the X server. The MyXGrabServer() function in libs/Grab.c does this, and we really must never call XGrabServer or XUngrabServer directly anywhere else because My...() does reference conting (I'll fix that in my next patch). However, I have no idea why the XSync() call is necessary. I've never seen any documentation that mentions it, but real life shows that it is necessary (perhaps only with XFree86/Xorg?). [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 always have to cope with unexpected errors anyway. 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. Using MyX(un)Grabserver() should fix this. 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. [snip] Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: SIGSEGV in colorset.c
On Fri, Feb 01, 2008 at 01:02:05AM +0600, Roman Dubtsov wrote: I have intermittent FVWM crashes. They occur when I start either gnome-control-center, nvidia-settings, or wine (this one works almost always). I use FVWM from Debian. [EMAIL PROTECTED] 00:51:32 fvwm-cvs]$ fvwm -V fvwm 2.5.23 compiled on Jan 31 2008 at 23:37:18 with support for: ReadLine, RPlay, Stroke, XPM, PNG, SVG, Shape, XShm, SM, Bidi text, Core is not always dumped, sometimes FVWM crashes with X11 error message similar to this: [fvwm.0][FvwmErrorHandler]: ERROR *** internal error *** [fvwm.0][FvwmErrorHandler]: ERROR Request 73, Error 8, EventType: 28 But today I was able to obtain a core dump and trace SEGFAULT to particular line of colorset.c: (gdb) bt #0 0x080a723e in parse_colorset (n=11, line=0x80eba93 RootTransparent) at /home/busa/buildspace/x11/wm/fvwm/fvwm-2.5.23/fvwm/colorset.c:1170 #1 0x080a826c in update_root_transparent_colorset (prop=287) at /home/busa/buildspace/x11/wm/fvwm/fvwm-2.5.23/fvwm/colorset.c:1776 #2 0x0806d328 in HandlePropertyNotify (ea=0xbfd725f4) at /home/busa/buildspace/x11/wm/fvwm/fvwm-2.5.23/fvwm/events.c:3177 #3 0x0806c001 in dispatch_event (e=0xbfd72624) at /home/busa/buildspace/x11/wm/fvwm/fvwm-2.5.23/fvwm/events.c:3926 #4 0x0806c718 in HandleEvents () at /home/busa/buildspace/x11/wm/fvwm/fvwm-2.5.23/fvwm/events.c:3967 #5 0x0808d955 in main (argc=2, argv=0xbfd730d4) at /home/busa/buildspace/x11/wm/fvwm/fvwm-2.5.23/fvwm/fvwm.c:2610 Apparently, it is the place where average color is calculated. The definition of 11 colorset is as follows: Colorset 11 fg #D7D9DD, RootTransparent, Tint white 30, sh #404040, hi #404040 Is there anything else I can do to help to resolve the issue? colorset.c in CVS head did not change since 2.5.23, so I did not build and test it, but will surely do if necessary. Should be fixed with my latest commit. I think the X error should be gone too. Can you try it and look if the X error reappears, pease? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: SIGSEGV in colorset.c
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
Re: FVWM: SIGSEGV in colorset.c
On Saturday 02 February 2008, Viktor Griph wrote: ...snip... 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.) Thanks! I'll try. Somehow, I was thinking that it is impossible to specify bg with RootTransparent. Regards, Roman
Re: FVWM: SIGSEGV in colorset.c
On Sat, 2 Feb 2008, Roman S Dubtsov wrote: On Saturday 02 February 2008, Viktor Griph wrote: ...snip... 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.) Thanks! I'll try. Somehow, I was thinking that it is impossible to specify bg with RootTransparent. Just remember to remove the bg if we ask you to try to reproduce the bug again. It won't happen without bg-averaging. /Viktor
Re: FVWM: SIGSEGV in colorset.c
On Fri, 1 Feb 2008, Roman Dubtsov wrote:
Hello,
I have intermittent FVWM crashes. They occur when I start either
gnome-control-center, nvidia-settings, or wine (this one works almost
always). I use FVWM from Debian.
[EMAIL PROTECTED] 00:51:32 fvwm-cvs]$ fvwm -V
fvwm 2.5.23 compiled on Jan 31 2008 at 23:37:18
with support for: ReadLine, RPlay, Stroke, XPM, PNG, SVG, Shape, XShm,
SM, Bidi text,
Core is not always dumped, sometimes FVWM crashes with X11 error
message similar to this:
[fvwm.0][FvwmErrorHandler]: ERROR *** internal error ***
[fvwm.0][FvwmErrorHandler]: ERROR Request 73, Error 8, EventType: 28
That is a BadMatch error from XGetImage (probalby line 1149 in
colorset.c), which would then return null, and explain the segfault on
line 1170. According to the man page of XGetImage, that is caused by
trying to read outside the pixmap. Which seems quite strange since on line
1045-1048 the pixmap and size is set to that of the root_pic. And it then
verifies the with at line 1102-1121, and the XServer is grabbed during the
test until after the XGetImage call.
Is there anything else I can do to help to resolve the issue?
colorset.c in CVS head did not change since 2.5.23, so I did not build
and test it, but will surely do if necessary.
I'm interesting in having verified that cs-picture == NULL for the
colorset, and also have the with and hight queried from the image before
the XGetImage printed. I must be missing some possible path here. But I
fail to see how the picture can be non-NULL - at least not with your
Colorset definition.
Can you add something like
{
int w;
int h;
XID dummy;
if (
!XGetGeometry(
dpy, average_pix, dummy,
(int *)dummy, (int *)dummy,
(unsigned int *)w, (unsigned int *)h,
(unsigned int *)dummy,
(unsigned int *)dummy))
{
fprintf(stderr, failed to get dimension\n);
}
else
{
fprintf(stderr, width: %d, height: %d, expexted: %dx%d\n,
w, h, cs-width, cs-height);
}
fprintf(stderr, picture: %p\n, cs-picture);
}
before the call to XGetImage? And try to reproduce the error.
/Viktor
Re: FVWM: SIGSEGV in colorset.c
On Fri, Feb 01, 2008 at 01:02:05AM +0600, Roman Dubtsov wrote: I have intermittent FVWM crashes. They occur when I start either gnome-control-center, nvidia-settings, or wine (this one works almost always). I use FVWM from Debian. [EMAIL PROTECTED] 00:51:32 fvwm-cvs]$ fvwm -V fvwm 2.5.23 compiled on Jan 31 2008 at 23:37:18 with support for: ReadLine, RPlay, Stroke, XPM, PNG, SVG, Shape, XShm, SM, Bidi text, Core is not always dumped, sometimes FVWM crashes with X11 error message similar to this: [fvwm.0][FvwmErrorHandler]: ERROR *** internal error *** [fvwm.0][FvwmErrorHandler]: ERROR Request 73, Error 8, EventType: 28 Hm, fvwm really doesn't crash just because of an X error. I've heard about this crash without core on X error stuff several times, but I don't know what's going on. Maybe the X server itself crashes. But today I was able to obtain a core dump and trace SEGFAULT to particular line of colorset.c: (gdb) bt #0 0x080a723e in parse_colorset (n=11, line=0x80eba93 RootTransparent) at /home/busa/buildspace/x11/wm/fvwm/fvwm-2.5.23/fvwm/colorset.c:1170 #1 0x080a826c in update_root_transparent_colorset (prop=287) at /home/busa/buildspace/x11/wm/fvwm/fvwm-2.5.23/fvwm/colorset.c:1776 #2 0x0806d328 in HandlePropertyNotify (ea=0xbfd725f4) at /home/busa/buildspace/x11/wm/fvwm/fvwm-2.5.23/fvwm/events.c:3177 #3 0x0806c001 in dispatch_event (e=0xbfd72624) at /home/busa/buildspace/x11/wm/fvwm/fvwm-2.5.23/fvwm/events.c:3926 #4 0x0806c718 in HandleEvents () at /home/busa/buildspace/x11/wm/fvwm/fvwm-2.5.23/fvwm/events.c:3967 #5 0x0808d955 in main (argc=2, argv=0xbfd730d4) at /home/busa/buildspace/x11/wm/fvwm/fvwm-2.5.23/fvwm/fvwm.c:2610 Apparently, it is the place where average color is calculated. The definition of 11 colorset is as follows: Colorset 11 fg #D7D9DD, RootTransparent, Tint white 30, sh #404040, hi #404040 Is there anything else I can do to help to resolve the issue? Yes, if you still have the core, run the following gdb commands: $ gdb fvwm core (gdb) bt (gdb) info locals (gdb) info args (gdb) p *cs (gdb) p k (gdb) p colors[k-1] (gdb) p colors[k] (gdb) up (gdb) info locals (gdb) info args (gdb) p *cs (gdb) up (gdb) info locals (gdb) info args (gdb) p *te Then post all the output. Also, I need *all* your colour set definitions and all config lines that use them. It's probably best to post your whole config file. I'll be away for a couple of days, but I'll look into the problem next week. colorset.c in CVS head did not change since 2.5.23, so I did not build and test it, but will surely do if necessary. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: SIGSEGV in colorset.c
On Thu, Jan 31, 2008 at 10:08:47PM +0100, Viktor Griph wrote: On Fri, 1 Feb 2008, Roman Dubtsov wrote: Hello, I have intermittent FVWM crashes. They occur when I start either gnome-control-center, nvidia-settings, or wine (this one works almost always). I use FVWM from Debian. [EMAIL PROTECTED] 00:51:32 fvwm-cvs]$ fvwm -V fvwm 2.5.23 compiled on Jan 31 2008 at 23:37:18 with support for: ReadLine, RPlay, Stroke, XPM, PNG, SVG, Shape, XShm, SM, Bidi text, Core is not always dumped, sometimes FVWM crashes with X11 error message similar to this: [fvwm.0][FvwmErrorHandler]: ERROR *** internal error *** [fvwm.0][FvwmErrorHandler]: ERROR Request 73, Error 8, EventType: 28 That is a BadMatch error from XGetImage (probalby line 1149 in colorset.c), which would then return null, and explain the segfault on line 1170. According to the man page of XGetImage, that is caused by trying to read outside the pixmap. Which seems quite strange since on line 1045-1048 the pixmap and size is set to that of the root_pic. And it then verifies the with at line 1102-1121, and the XServer is grabbed during the test until after the XGetImage call. The root pixmap may change while the function is running; so the returned pixmap may already be destroyed when GetImage is called. This might happen when using FvwmBacker, fvwm-root, esetroot or similar programs. Is there anything else I can do to help to resolve the issue? colorset.c in CVS head did not change since 2.5.23, so I did not build and test it, but will surely do if necessary. I'm interesting in having verified that cs-picture == NULL for the colorset, and also have the with and hight queried from the image before the XGetImage printed. I must be missing some possible path here. But I fail to see how the picture can be non-NULL - at least not with your Colorset definition. It doesn't need to be NULL. See above. Also not that the given colorset can't be responsible for the crash because it does not have the bg_average bit. Anyway, we definitely need to check the result of XGetImage in all places where it's called (colorset.c, ewmh_icons.c, FImage.c) and implement some fallback strategy. [snip] Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: SIGSEGV in colorset.c
On Fri, Feb 01, 2008 at 01:10:43PM +0600, 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. 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. 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). I could take just a quick look at the output. We have average_pixmap = something != 0 cs-width = 720 cs-height = 360 image = 0 k = 0 The config consists of multiple files that are sourced from .fvwm/config. All colorset definitions and some uses are in data/decorations/current/script (Translucent is a left-over from the times I used that patch, now I don't). Other files where colorsets are used are: * data/panels/combopanel-horz * data/scripts/FvwmScript-NetworkPanel * data/scripts/FvwmScript-ClockCalendar 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. 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. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
