Bug#181951: libc6: Libc6 doesn't draw "top" screen correctly
At Sun, 23 Feb 2003 12:17:04 -0500,
Daniel Jacobowitz wrote:
>
> On Mon, Feb 24, 2003 at 12:49:59AM +0900, GOTO Masanori wrote:
> > At Sat, 22 Feb 2003 18:28:11 +0200 (EET),
> > Joonas Paalasmaa wrote:
> > > On Sat, 22 Feb 2003, GOTO Masanori wrote:
> > > > At Sat, 22 Feb 2003 10:06:04 +0200 (EET),
> > > > Joonas Paalasmaa wrote:
> > > > > On Sat, 22 Feb 2003, GOTO Masanori wrote:
> > > > > > At Fri, 21 Feb 2003 17:37:08 +0200,
> > > > > > joonas.paalasmaa@iki.fi wrote:
> > > > > > > When using libc6 2.3.1-11, screen of command "top" is drawn incorrectly,
> > > > > > > whereas when version 2.2.5-11.2 is used, top functions in the right way.
> > > > > > > With 2.2.5-11.2 the first line of top's output is not shown if the number
> > > > > > > of processes is so big that the list of them has to be truncated.
> > > > > > >
> > > > > <snipped>
> > > > > >
> > > > > > My procps (Version: 1:3.1.5-1) shows in the right way.
> > > > > > The top displays on my machine:
> > > > > >
> > > > > <correct top display snipped>
> > > > > >
> > > > > > Which version is your procps? It seems your version is old.
> > > > > > Did you upgrade only libc6? Many packages depends on libc6, so you
> > > > > > install many packages at the same time.
> > > > > >
> > > > > > I doubt it's libc6 problem. Please recheck, otherwise I close this bug.
> > > > >
> > > > > I upgraded procps from 1:2.0.7-8 to 1:3.1.5-1 and the problem disappeared.
> > > >
> > > > That's good.
> > > >
> > > > > Nevertheless, there is still some kid of a bug in libc6 2.3.1-11.
> > > > > I ran top 1:2.0.7-8 with chroot to check how it works with different
> > > > > libraries. With ld-linux.so.2 symlinked to ld-2.2.5.so and libc.so.6 symlinked
> > > > > to libc-2.2.5.so, top 1:2.0.7-8 functioned properly. Then I symlinked
> > > > > ld-linux.so.2 to ld-2.3.1.so and libc.so.6 to libc-2.3.1.so, and top 1:2.0.7-8
> > > > > didn't show the first line anymore.
> > > >
> > > > I don't know why such problem is occured.
> > > >
> > > > I have a local build procps 1:2.0.6-5 (to investigate something), and
> > > > it works well. I retrive procps 1:2.0.7-8 from snapshot.debian.net,
> > > > (http://snapshot.debian.net/archive/2002/06/04/debian/pool/main/p/procps/)
> > > > then extract and use it on sid environment, it also works well:
> > > >
> > > > 00:01:06 up 15 days, 1:42, 28 users, load average: 0.10, 0.17, 0.11
> > > > 174 processes: 173 sleeping, 1 running, 0 zombie, 0 stopped
> > > > CPU states: 16.3% user, 1.3% system, 0.1% nice, 82.3% idle
> > > > Mem: 1031476K total, 1018908K used, 12568K free, 253108K buffers
> > > > Swap: 2048216K total, 169116K used, 1879100K free, 436480K cached
> > > >
> > > > PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
> > > > <snip>
> > > >
> > > > I guess it's something other problem rather than glibc. Please recheck.
> > >
> > > To completely isolate the problem, I tested it once again with chroot
> > > and tarred all libraries I used in testing. The package can be downloaded
> > > at http://speedloop2000.com/libc6-test.tar.bz2 . Download the archive
> > > and issue the following commands, and you should see two kinds of top
> > > behaviour with different libc6 versions. At least on my computer, on
> > > virtual terminal.
> >
> > Thanks for your test case, but it works well...
> >
> > 15:45:58 up 13 days, 20:41, 0 users, load average: 0.31, 0.19, 0.07
> > 76 processes: 75 sleeping, 1 running, 0 zombie, 0 stopped
> > CPU states: 0.1% user, 0.2% system, 0.0% nice, 99.7% idle
> > Mem: 1034604K total, 1007512K used, 27092K free, 172804K buffers
> > Swap: 249944K total, 1696K used, 248248K free, 728224K cached
> >
> > Please check your environment variable especially $TERM (I checked
> > with "xterm" and "vt100"), $LANG (I checked with "C"), kernel version
> > (I checked with 2.4.19/2.5.59), etc...
>
> He said he was using a virtual terminal, by which I assume he means a
> VC and TERM=linux.
I test on VC (TERM=linux), but still I don't look any problem.
Is this really glibc issue?
Regards,
-- gotom
Reply to: