On Sun, Jan 15, 2023 at 07:14:24PM +0100 I heard the voice of
Rhialto, and lo! it spake thus:
>
> Unfortunately I got a core dump from cwtm (compiled Dec 17).
[...]
> (gdb) print cmap
> $1 = (TwmColormap *) 0x101000100000001
>
> (gdb) print *cwin
> $2 = {w = 79691778, colormap = 0x101000100000001, visibility = 2047083,
> refcnt = 1}
That's a new one on me. Every time I see colormaps I cry a little
inside, but I haven't seen them crash anything ever and I dunno what
could be causing that...
In a little poking, everything should funnel through
CreateColormapWindow(), which seems like (after it stashes the
ColormapWindow in the context, but hey, who needs ordering...) it
should either be pulling an existing colormap (from a previous
runthru) or creating a new one via CreateTwmColormap(). Either way it
should be some malloc'd space and a valid pointer (or at least NULL).
I find the ->visibility there a little weird too. Either we set that
to one of the VisibilityFoo defines, or it gets set to the state from
a XVisibilityEvent which is defined to be one of them as well (x-ref
https://www.x.org/releases/current/doc/man/man3/XVisibilityEvent.3.xhtml
and HandleVisibilityNotify()). And...
% grep -E 'Visibility.*bscur' /usr/local/include/X11/X.h
#define VisibilityUnobscured 0
#define VisibilityPartiallyObscured 1
#define VisibilityFullyObscured 2
It takes a lot of 0's, 1's, and 2's to wind up as 2047083. So,
something's pretty bogus about that whole ColormapWindow.
> I was just doing something with it when ctwm crashed (I think making
> it fullscreen or something).
Really not fair, that's supposed to crash the OTP stuff.
Hey, we can just assume everybody's running 24bpp by now, and
eliminate separate per-window colormaps entirely, right? That's
definitely a small simple change that won't break anything...
--
Matthew Fuller (MF4839) | fulle...@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
