Re: mvwprintw

[Bob Rossi]

On Thu, Mar 30, 2006 at 03:44:04PM -0500, Thomas Dickey wrote:
> On Thu, 30 Mar 2006, Bob Rossi wrote:
> 
> >On Thu, Mar 30, 2006 at 01:19:43PM -0500, Bob Rossi wrote:
> >>On Thu, Mar 30, 2006 at 01:01:13PM -0500, Thomas Dickey wrote:
> >>>On Thu, 30 Mar 2006, Bob Rossi wrote:
> >>>
> >>>>Can a char string like this:
> >>>>
> >>>>$7 = 0x810e700 "(tgdb) b main.c:7                   ..."  where the
> >>>>string is 81 characters long, and from the '7' up until char 80 they
> >>>>are all spaces, and char 81 is the NUL char.
> >>>>
> >>>>be used with the function like this?
> >>>>mvwprintw(win, 13, 0, "%s", buffer);
> >>>>where buffer is the string above.
> 
> In the original report I didn't understand what "curropt" is.  Can you
> clarify that remark?

Yes, for some strange reason, even though I can program, I still spell
like a second grader. I meant to say, corrupt.

> >>>It looks ok to me - how big is the window?
> >>
> >>It's 60 rows x 80 columns. This is a frustrating bug to find. I've been
> >>looking at it for an hour and have haven't got anywhere.
> 
> So the window is 80 columns and presumable also the terminal.  Offhand
> I don't know of wrapping problems (except for people who set TERM to 
> "xterm" while using PuTTY).  What is TERM and the actual terminal 
> emulator?

I'm using putty and my "Terminal-type string" is "xterm" and my $TERM
can be either xterm or xterm-color.

Once logged in, if I open an xterm, with TERM=xterm or TERM=xterm-color,
I still have the problem.

> (of course this is bug-ncurses list - if I had a short test program
> for the feature, I could test that and see if I got the same result).
> 
> >>I did notice that my application was sending ^G (bell character) on
> >>stderr. Would this screw something up?
> 
> no (unless the ^G is being echoed as "^" and "G").

OK, I also closed stderr so that the ^G isn't sent, and the problem
still exists.

> >>I can't figure out why the terminal is printing currupt data when it
> >>appears that I am passing it a normal string. I ran it through valgrind,
> >>and it didn't detect any problems. :(
> >
> >OK, I downloaded the latest ncurses. The problem still exists. However,
> >when I build ncurses with trace and have NCURSES_TRACE set or not,
> >everything works fine. This really bothers me.
> 
> That sounds like the "still exists" case is picking up the original
> shared library (which you can verify with ldd).  It's possible that
> the traces make some side-effect, but it's been quite a while since
> anyone reported _that_ problem.

I'm using the new ncurses.

When I build with trace like so,
../ncurses-5.5/configure CFLAGS=-g --with-shared --without-cxx 
--without-cxx-binding --without-ada --with-trace 
--prefix=/home/bar/cvs/cgdb/cgdb-cvs/ncurses/target-trace
and then do 
$ ldd ./cgdb/src/cgdb
        libm.so.6 => /lib/tls/libm.so.6 (0xb75be000)
        libtermcap.so.2 => /lib/libtermcap.so.2 (0xb75ba000)
        libncurses.so.5 => 
/home/bar/cvs/cgdb/cgdb-cvs/ncurses/target-trace/lib/libncurses.so.5 
(0xb7562000)
        libc.so.6 => /lib/tls/libc.so.6 (0xb742a000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb75eb000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7427000)

My NCURSES_TRACE env var is not set. I still get the bug.
If I do 'export NCURSES_TRACE=8191', I still get the bug.

If I recompile CGDB with ncurses_g (not sure if this used
/usr/lib/libncurses_g.a or the one in
/home/bar/cvs/cgdb/cgdb-cvs/ncurses/target-trace/lib/libncurses_g.a.
I think it used the newone because GDB reports on the source files from
that library.

My NCURSES_TRACE env var is not set. I do not get the bug.
If I do 'export NCURSES_TRACE=8191', I do not get the bug.

So I guess it's not a function of NCURSES_TRACE. But switching libraries
between libncurses and libncurses_g does show a difference. Any
suggestions?

I've been debugging ncurses, but can't figure out what's wrong.

Bob Rossi