Bug 524503

I don't see an obvious cause in the walkback, since
DamagedCells is in a context where it "should" work.
However, if there's some coding error from a different
point, then ld could be null.  In that case, adding
a null-pointer check just before line 110, and returning
false would help.

A "different point", for example, would be in the resizing
code, which is where some of the recent bug-fixes were.

(In reply to comment #1)
> However, if there's some coding error from a different
> point, then ld could be null.  In that case, adding
> a null-pointer check just before line 110, and returning
> false would help.

I posted some more gdb output right after the backtrace where I examined a few variables. ld doesn't appear to be null, but ld->charData points to garbage.

I see (didn't notice).  Doing a "print *ld" would
show the other struct members, which I assume are
all incorrect.

Also, going up the stack to screen.c line 1274, there
should be a comparable ld value.

Does this crash in the same place, each time?

Note that I'm examining another trace this time, so some values might be a bit different than in the first backtrace posted. It crashed in the exact same place though.


> I see (didn't notice).  Doing a "print *ld" would
> show the other struct members, which I assume are
> all incorrect.

(gdb) frame
#0  0x0000000000440eb8 in DamagedCells (screen=0x8af858, n=141, klp=0x7fffffffdc08, krp=0x7fffffffdc04, row=66, col=0) at ./util.c:110
110         if (ld->charData[kl] == HIDDEN_CHAR) {
(gdb) info local
ld = 0x9a63f0
kl = 0
kr = 141
(gdb) print *ld
$3 = {lineSize = 141, bufHead = 0 '\000', combSize = 2 '\002', attribs = 0x2000000020 <Address 0x2000000020 out of bounds>,
  color = 0x2000000020, charData = 0x2000000020, combData = {0x2000000020}}


> Also, going up the stack to screen.c line 1274, there
> should be a comparable ld value.

I can't see any frame at screen.c:1274 in this backtrace, but I'll show you *ld from util.c:1273 instead.

(gdb) up
#1  0x000000000043b9a4 in ScrnClearCells (xw=0x8af6e0, row=51, col=0, len=141) at ./screen.c:704
704         if_OPT_WIDE_CHARS(screen, {
(gdb) info local
kl = 9107168
kr = 51
screen = 0x8af858
flags = 0
(gdb) up
#2  0x0000000000443fb6 in ClearRight (xw=0x8af6e0, n=141) at ./util.c:1273
1273            ScrnClearCells(xw, screen->cur_row, screen->cur_col, len);
(gdb) info local
screen = 0x8af858
ld = 0x9a6120
len = 141
(gdb) print *ld
$6 = {lineSize = 141, bufHead = 0 '\000', combSize = 2 '\002',
  attribs = 0xb2d8f8 "\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200", color = 0xb2d988,
  charData = 0xb2daa4, combData = {0xb2dcd8}}


> Does this crash in the same place, each time?  

Yes, it always crashes in the same place.

thanks - I'm assuming that one of the limit checks for
index/row translation is hitting a boundary.  I'll pick
through this and see if I can spot the problem.

I think the problem is an error in the way I mapped the
row indices (mostly changes from 2007), which could break
if you happen to have xterm scrolled back, e.g., for a
selection, while an application is updating the screen.

For instance, the INX2ROW() on line 1223 of screen.c looks
like the immediate problem - I'll investigate and see.

...I meant INX2ROW on line 707 actually ;-)

But I am able to reproduce the problem (that INX2ROW is incorrect).
I'll review more from that slice and fix what I can find.

thanks

Thanks for the very fast investigation, Thomas. Let me know if you need me to test anything else.

no - I have enough data (thanks).  I'm about 2/3 through reviewing
the places where I used that macro.

We have beta freeze today, so I've included upstream patch 248c + one hunk from 248e.

Should be fixed in xterm-248-2.fc12. Please reopen if it doesn't fix the issue. Thanks.

sounds good...

I can confirm that the issue I was seeing is now fixed. Thanks!