2009/6/27 Thomas Adam <thomas.ada...@gmail.com>:
> 2009/6/27 Christian Ohm <chr....@gmx.net>:
>> On Friday, 26 June 2009 at 23:46, Thomas Adam wrote:
>>> So it's failing due to a bad colour -- but your config doesn't show
>>> that which is why it's working fine for me.
>>>
>>> Please attach this corefile you have and your *full* fvwm config and I
>>> shall track it down for you.
>>
>> This config is all I need to get the segfault, on a current Debian unstable
>> system that never saw fvwm before. If you still need the coredump, I'll send
>> it
>> tomorrow (it's on another machine).
>
> It's not segfaulting for me -- how are you invoking FVWM? I might ask
> you to compile ds-4's sources with the DEBUG flag to FVWM if this
> persists -- but this is working as expected so until then, don't
> bother.
>
> I am a little confused why the backtrace shows the problem in
> ColorUtils.c -- that *really* is at the point the colours are parsed
> -- it's actually failing here:
>
> if (name && strncasecmp(name, "rgb:", 4) == 0)
>
> Odd. Regardless of your assertion that your previous config snippet
> still exhibits the problem, I would still like you to upload your
> entire FVWM config, and yes, supply the corefile as well, I'd like to
> analyse it for myself.
Don't bother. I've fixed it. I was unaware that the patch in bug
#529036 had been applied -- damn it, this isn't even applied here at
*upstream* -- no wonder it wasn't working for me -- I was looking at
tained code I wouldn't have otherwise had *access* to. This is a
common occurence of many distros, where they willingly apply patches
outside of the vanilla code they receive from upstream on complete and
utter blind faith -- well, on this occasion it bombed. No surprise
there -- I can only apologise to you, Christian, for this -- it's
certainly dented any credability for the work I've put in to making
the FVWM debian package better. I'm just pleased this wasn't
forwarded directly to upstream. :|
Anyway -- rant over. I was able to reproduce the problem locally,
albeit with slightly different symptoms to yourself. I didn't get a
direct crash like you did, I saw the following in my logs:
Cannot parse color "blank".
Hmm. That's odd. From your backtrace though, I tracked it down to here:
modules/FvwmIconMan/x.c:572 -- which looks like this:
static int load_default_context_back (WinManager *man, int i)
This is called each time options are being set in the default context,
which looks like this:
ContextDefaults contextDefaults[] = {
{ "plain", BUTTON_UP, { "black", "black" }, { "white", "gray"} },
{ "focus", BUTTON_UP, { "white", "gray" }, { "black", "black" } },
{ "select", BUTTON_FLAT, { "black", "black" }, { "white", "gray" } },
{ "focusandselect", BUTTON_FLAT, { "white", "gray" }, { "black",
"black" } },
{ "title", BUTTON_EDGEUP, { "black", "black"}, {"white", "gray"} },
{ "icon", BUTTON_FLAT, { "black", "black"}, {"white", "gray"} },
{ "default", BUTTON_FLAT, { "black", "black"}, {"white", "gray"} },
Via some simple fprintf() statements, I realised there was an
off-by-one when iterating that array. When I go to look up this, I
notice the following:
typedef enum {
DEFAULT = 0,
FOCUS_CONTEXT = 1,
SELECT_CONTEXT = 2,
/* had better be FOCUS_CONTEXT | SELECT_CONTEXT */
FOCUS_SELECT_CONTEXT = 3,
PLAIN_CONTEXT = 4,
TITLE_CONTEXT = 5,
ICON_CONTEXT = 6,
ICON_SELECT_CONTEXT = 7,
NUM_CONTEXT
} Contexts;
Oops! This isn't right -- the *only* reason I knew the patch from bug
#529036 caused this error was due to the value of
"ICON_SELECT_CONTEXT" in the enum -- which shouldn't be there, but I'd
remembering reading about that bug earlier. Unfortunately, what the
author of this "enhancement" patch didn't realise is that NUM_CONTEXT
is paramount in its order within the enum -- it has to have a value of
7 for a good reason -- coun't the number of entries in the
contextDefaults[] array -- and guess what. :P
So, the fix is simple -- see the patch attached.
Manoj -- please be very careful in future what you're applying outside
of upstream; *especially* if it's code-related. That only makes
tracking down bugs even more worrisome because *I* and *others* *have*
*to* *know* there's potential code modifiying other things. As it
stands, I would recommend you back out this the patch from bug #529036
entirely -- I am aware of its presence upstream, and will eventually
get around to looking at it properly. For now though, it's
potentially causing problems. I will produce a separate reply on this
in bug #529036 --- and I'd appreciate it if this bug and #529036 were
dependencies of one another.
-- Thomas Adam
--- FvwmIconMan.h 2007-01-28 15:29:26.000000000 +0000
+++ /tmp/fvwm-2.5.27.ds/modules/FvwmIconMan/FvwmIconMan.h 2009-06-27 19:21:15.000000000 +0100
@@ -100,7 +100,8 @@
PLAIN_CONTEXT = 4,
TITLE_CONTEXT = 5,
ICON_CONTEXT = 6,
- NUM_CONTEXTS
+ NUM_CONTEXTS = 7,
+ ICON_SELECT_CONTEXT,
} Contexts;
typedef enum {
