[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mvwprintw

From: Bob Rossi
Subject: Re: mvwprintw
Date: Mon, 3 Apr 2006 14:47:54 -0400
User-agent: Mutt/1.5.9i

> hmm - go back to my last explanation.  The screen is being corrupted 
> because either ncurses or some other code is writing bad data.  If it is 
> ncurses, you should be able to see it by tracing the low-level function
> PutAttrChar(), which is actually doing the output to the screen.  The 
> trace you sent should have showed PutAttrChar(), but did not.
> I'd see why it did not, and fix that (perhaps I misread the trace-level).
> Then see if PutAttrChar() is getting bad data, or making it bad - there's
> one call to PUTC() in tty_update.c which is doing the work.

OK, I have verified that the corruption for me does not happen in the
function PutAttrChar. 

Basically, I started CGDB. Attached to it with GDB and did 
'call trace (8191)'. Then I typed 'a', in the CGDB window. Then I called 
'call trace (0)' in GDB. When I looked at the trace file there was 
  PutAttrChar({'a' = 0141}) at (59, 7)

However, I start CGDB and type 'b main.c:7' and then type the back
arrow 5 times. Then I attach with GDB and do 'call trace (8191)'. Then in 
the CGDB window I type the forward arrow twice, the corruption 
shows up. In the GDB I type 'call trace (0)'. Then in the CGDB window I
quit. There is not a single instance of PutAttrChar.

I've attached the trace file that has the corruption. Does anything stick 
out with this new info?

Thanks for all your help! I'll continue to look if something in my
program is writing to stdout. However, that task could prove difficult
short of recompiling the C library and setting a breakpoint on 'write'.

Bob Rossi

Attachment: trace
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]