On Fri, Jan 20, 2023 at 08:40:27PM +0100 I heard the voice of
Rhialto, and lo! it spake thus:
>
> Somehow it feels like something is overwriting the contents of the
> *cwin struct; the values look too wrong to be able to be derived
> from a proper assignment. In particular the 0x101000100000001 feels
> like a bitmask...
Yah; and the visibility thing I noted points at similar ("this isn't a
ColormapWindow", rather than the "->colormap got overwritten somehow"
case). Though note that's a 0x not a 0b, so if it were a bitmask,
it'd be a 64-bit one. Which I'm fairly sure we don't have, so it'd be
2 32-bitters in a row, which also we don't obviously have, or it's a
couple short's that contain small offets or borders or the like.
A quick grep over our structs doesn't suggest any likely candidates
that have a Window first followed by that sorta thing (it does look
like a Window normally does, and you said it corresponded with a win
that was actually on your screen and you were interacting with). If
it's in the middle of a struct, I ain't gonna spend the time reading
around to guess what it might be.
But how would it get there, even if we knew what else it would be?
There's nowhere we'd be writing something else into the
ColormapContext, so it'd have to somehow get free()'d and reused by
something else. I don't see any obvious place we'd do that. We'd
free the old ->colormap in HandleColormapNotify(), but we'd have
already changed cwin->colormap in that case (and that would just
result in garbage in the ->colormap anyway, not in the whole cwin).
I guess there are two cases. The "cwin in context got free'd and
reused" is the above, which I don't see a path to. The alternative
would be "XFindContext didn't actually load anything, but we proceeded
anyway and so cwin is uninitialized stack garbage, that happened to
point to some other struct somewhere". How could it happen?
vtwm looks just like us. Current twm uses XFindContext==0 instead of
!=XCNOENT in the condition in its HandleVisibilityNotify(). Commit
log just indicates it was some reorganizing done for strict-aliasing
warnings. The manual says XCNOENT is the only failure case.
Inspecting libX11 source agrees with that. So, that doesn't seem
likely either; if we get that far, FindContext must have succeeded, so
the stack garbage case seems out.
I dunno. This seems a long way off from any code we've touched in my
memory, which means it'd have to be a long-standing bug, which just
makes it weird that you'd come across it now. Which also makes it
sound pretty hard to reproduce :(
I s'pose the backtrace could just be completely bogus. Source tree
doesn't match the running binary? But the only change in trunk since
your build date was in add_window.c, so I don't see how that could
throw it off in a way that would make as much internal sense...
--
Matthew Fuller (MF4839) | fulle...@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
