hmm. It's supposed to work. However, for background: most of the changes from 244 are restructuring changes (actually, making structs for the index of line-data). So before, I had something like unsigned char *a; unsigned char *b; unsigned char *c; unsigned char *d; and now it's a struct which can have different pointer types than unsigned char *. The enable-fifo-lines option turns on/off a modification which lets the saved-line area be a separate memory buffer from the visible-lines. In turn, that saved-line area is accessed as a circular buffer. Because of the way saved-lines and visible-lines were all one array, the new scheme has several special cases - and up to this point, I've been assuming the problems lie just in that chunk - particularly since more than half of the code related to just enable-fifo-lines is in the resizing logic. However - in that "most of the changes" chunk, it may address memory differently, and we may be looking for a subscripting error, etc. If I were able to reproduce this, I'd build xterm using the --enable-trace option, to see if that gave me more information. Besides writing to Trace-parent.out the display information, it turns on several assert's (which may catch the problem a little earlier). There's a little more trace that could be turned on by #define'ing OPT_TRACE to 2, though I'm not sure if that's needed. But that's where I'd start - to find xterm's sizes for the buffer. -- Thomas E. Dickey <dickey@invisible-island.net> http://invisible-island.net ftp://invisible-island.net
Attachment:
signature.asc
Description: Digital signature