On Fri, Mar 31, 2006 at 02:53:44PM -0500, Thomas Dickey wrote:
On Fri, 31 Mar 2006, Bob Rossi wrote:
OK, here is the script file that has the error. I also have the the
output of unmap attached. I am having a little trouble reading these
files for the first time. I suppose I better get good at it.
See anything interesting?
I don't see the \E[1C split-up in this trace, but find it unusual to
see a long string of nulls (^@) after the chunk:
\n^N^O~^Nx^O
\E[27;4H^N^O
\E[60;8Hb main.c:777777777777
\E[21Db
main1Cc:address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@^@
There's not much here to read:
^N and ^O switch to/from line-drawing mode
\E[60;8H moves the cursor to cell 60,8
\E[21D moves the cursor left 21 cells
The \E's are escape characters. unmap renders all of the control
characters with either ^'s or \'s (it also makes a new line on each
escape character, to make it readable).
Referring back to your trace, I notice that the trace-level should be
high enough, but I don't see PutAttrChar lines in that. I'd expect
to see those immediately before individual characters are emitted.
Sometimes I add temporarily another call to _trace there to show
the actual bytes that are written - which is what I was considering
advising you to do to explore whether ncurses is emitting the ^@'s.
Right now, I'd suggest checking to see if PutAttrChar (in ncurses/tty)
is really being invoked, or if there's some bug in the tracing, etc.
Hi Thomas,
Sorry I haven't got to the bottom of this yet. Hopefully I'll find the
problem today. Since the debug doesn't seem to be helping to much here,
what's the lowest level function I should be debugging to determine why
my screen is getting corrupted?