[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fvwm
Subject:    Re: FVWM: SIGSEGV in colorset.c
From:       Dominik Vogt <dominik.vogt () gmx ! de>
Date:       2008-01-31 21:50:05
Message-ID: 20080131215005.GA3583 () gmx ! de
[Download RAW message or body]

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.
> >
> >[busa@stratosphere 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

[prev in list] [next in list] [prev in thread] [next in thread]