Bug#1057501: [procps] CPU usage in manual update of 'top' broken after upgrading to bookworm

[Jim Warner]

Hi Roman,

We discovered three potential instances of %Cpu distortion in release 4.0.2.

They were all fixed in release 4.0.4, which is available in trixie.

If you could try that package and report back it would be appreciated.

Thanks in advance.

Regards,

Jim

Bug#983771: procps: /bin/ps -A -o lxc,.. f with lxc as column on debian testing shows no lxc name, only '-'

[Jim Warner]

On Tue, 2 Mar 2021 07:31:33 +1100 Craig Small  wrote:


The lxc folks love changing the name of the cgroup on us so I suspect this
has happened (yet) again. The various names procps uses can be found at [1]

Can you pick one process you expect to see the lxc output for and send me
the output of /proc//cgroup ?


Hi Craig,

The lxc/lxd folks have not changed the default lxc prefix since release 
4.0.0 (now at 4.0.6).  But in that release they restored the configure 
option:

--with_cgroup_pattern=

I wonder if Andreas exploited that provision.  If so, perhaps by keeping 
the default pattern and just adding their own prefix the problem may be 
solved.


I have in ind something like this:
--with_cgroup_pattern=MY-PFX.lxc.payload.

( note the trailing '.', although '/' would work just as well )

On the other hand, if Andreas didn't re-build lxc, I think we're 
screwed.  I know of no way to extract an altered cgroup pattern at runtime.


Regards,

Jim

Bug#977893: procps: top does not sort correct by TIME

[Jim Warner]

Hi Michael,

That 'yyy' task is not the only out-of-order task.

The 2nd task shown would be misplaced if sorting on TIME+.

However, it looks to me that this sort was on %CPU.

Regards,

Jim

Bug#866106: no need to print trailing blanks

[Jim Warner]

On Tue, 27 Jun 2017 19:42:51 +0800 =?utf-8?B?56mN5Li55bC8?= Dan Jacobson 
 wrote:

Package: procps
Version: 2:3.3.12-3
Severity: minor
File: /usr/bin/top

It turns out that
$ top
prints trailing blanks all the way to the right edge of the screen.

The problem is gone in -b batch mode, but in interactive mode,
especially from remote systems, all those trailing blanks double the size
of traffic, all for no good.
It's as if one needs sed 's/ \+$//' to clean them up.


Hi Dan,

You may have your top configured such that trailing spaces exist but 
others may not.  The phenomenon you cite only occurs when a variable 
length field is displayed as the last field.


Besides, those trailing spaces are output only the first time a line is 
printed or when the line changes.  So you need not be concerned with 
overhead the doesn't exist.


Regards,
Jim

Bug#762928: debian bug #762928, top changed output

[Jim Warner]

Hi Thorsten,

My heart sank a bit when I read your bug report.

When I introduced the new graphs modes I had no intention of altering top’s 
behavior for those users with a previously saved rcfile.  Unfortunately, my 
implementation was a bit short of that goal.

There should soon be a patch available on the procps Gitorious repository to 
fix this problem.  In the meantime there are two ways of returning your 
previous defaults.

1) These keystrokes will restore previous behavior (sorry for the quantity):
t,t,t   # toggle Cpu display back to detail view
m,m # toggle Mem display back to detail view
E,E,E,E # toggle Summary memory scaling back to KiB
e,e,e,e # toggle Task memory scaling back to KiB

Once you’re comfortable with the display you can 'W' to preserve the 
configuration (be sure to answer 'y' to the overwrite prompt).
 
2) As an alternative, if you’re comfortable editing the .toprc file, after 
saving the new (undesired) configuration via 'W', the following elements 
can be changed:
graph_cpus=0, graph_mems=0  # 1 pair for each of 4 windows
Summ_mscale=0, Task_mscale=0# global settings on line 15

I’m sorry for the inconvenience, but thank you for the bug report.

Regards,
Jim


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762928: debian bug #762928, top changed output

[Jim Warner]

Hi Thorsten (again),

An afterthought.

Older tops will not be able to read a 3.3.10 rcfile.

Therefore, your only solution will likely be the patch I mentioned.

Regards,
Jim


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762947: debian bug #762947, Top outputs colors in Alt display

[Jim Warner]

Hi Antti,

The behavior you describe has not changed for over a decade.
That 'z' has always been window specific, affecting just a single window.
It’s documented in the man page under 4c. Task-Area-Commands.

What has changed are the startup defaults in the absence of a previously 
saved rcfile.  They now include colors unless top was built with 
./configure —disable-modern-top.

Unfortunately, not all aspects of saved rcfiles were honored.  Please see:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762928

I think that’s the bug which has put your eyes at risk.

A fix is on the way (but it only affects saved rcfiles).

I’ll ask Craig to close this report.

Regards,
Jim


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#627257: top: memory leaks

[Jim Warner]

Hi All,

I’m going to try to put this bug to rest, once and for all.

The top memory leak was serious, but top was a victim, not the culprit.

A fuller explanation can be found in message #27, which unfortunately is
not line wrapped thus making it more difficult to read.  So I’ll summarize
here:

1) A poorly designed patch adding supplementary group support to ps resulted 
in the library dynamically acquiring additional memory whenever /proc/#/status 
was accessed.

2) It was up to the caller to explicitly free that memory, which the ps 
program dutifully did.

3) Nobody bothered to inform the top program of this requirement so whenever
that directory was accessed, memory would be leaked.  It didn’t always happen
but required one of these fields to be displayed: PPID, RUSER, S or COMMAND.

All of that was fixed under procps-ng with release 3.3.0.  However, there 
remains these 2 valgrind lost categories, neither of which represent 
unintended memory leaks:

4) definitely lost
This is memory associated with the hashing in pwcache.c of results from 
getpwuid and getgrgid calls.  By design, memory is acquired that will never  
be freed if a user or group was not already hashed.

5) possibly lost
This is simply all of the dynamic memory (like that discussed above) plus 
the proc_t’s themselves representing the last top refresh cycle.  Since the 
program is ending, such memory will be freed automatically.

When Craig stated in message #27 that the memory leak is small and makes 
other parts more efficient , he was referring to points 4  5 above only.  
Unfortunately, Witold thought he was referring to the real leak discussed 
under points 1-3.

Please, close this darn bug.

Regards,
Jim


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#730460: memory leak in procps-ng

[Jim Warner]

Hi Jack, 

I’m the guy that added the readproc code you found suspect.

Please don't think of those buffers as representing a memory leak.  
Instead, think of them as being statically allocated like this:

#define MAX_BUFSZ 1024*64*2
static char src_buffer[MAX_BUFSZ],
dst_buffer[MAX_BUFSZ];

However, by being dynamically allocated we realize the following advantages:

1) Control of messaging is retained, if ever there was a true memory shortage.

2) All libproc users need not suffer the memory footprint increase.  
Only those calling openproc will have that memory allocated.

If the patch offered was applied, the top program would suffer severe 
performance 
degradation since it calls openproc/closeproc with every iteration.

As a general rule, any memory under the still reachable category is not a 
problem.  
This is from the valgrind documentation:

   still reachable means your program is probably ok — 
   it didn't free some memory it could have.
   This is quite common and often reasonable.

I’m going to ask Craig to close this bug report.

Regards,
Jim


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#721204: procps: top dies if -w is set to more than 527

[Jim Warner]

Lucas,

Thank you for spotting this this bug.

I'm sorry to say that I am the culprit responsible for it.

The top program will soon be fixed in our git repository which can be
found here:
http://gitorious.org/procps

Regards,
Jim


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#718670: top: don't just use comma on second line

[Jim Warner]

I'm going to side with the requester, not Craig, on this one.

Jidanni, how do you feel about something like this:

GiB Mem:  ... 1.941 used,3.786 free,0.178 buffers
GiB Swap: ... 0.000 used,8.456 free.0.944 cached Mem

Notice the period then the added 'Mem'.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#718670: top: don't just use comma on second line]]

[Jim Warner]

 Forwarded Message 
 From: jida...@jidanni.org
 To: james.war...@comcast.net
 Subject: Re: [Fwd: Re: Bug#718670: top: don't just use comma on second
 line]
 Date: Sat, 10 Aug 2013 05:50:42 +0800
 
  JW == Jim Warner james.war...@comcast.net writes:
 JW Sorry, I should have CC'd you just in case...
 Good thing else I won't get these.
 JW  Forwarded Message 
  From: Jim Warner james.war...@comcast.net
  To: 718...@bugs.debian.org
  Subject: Re: Bug#718670: top: don't just use comma on second line
  Date: Fri, 09 Aug 2013 09:53:18 -0500
 
  I'm going to side with the requester, not Craig, on this one.
 
  Jidanni, how do you feel about something like this:
 
  GiB Mem:  ... 1.941 used,3.786 free,0.178 buffers
  GiB Swap: ... 0.000 used,8.456 free.0.944 cached Mem
 
  Notice the period then the added 'Mem'.
 OK it's a deal! Go for it, folks.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#706259: Fwd: [amos...@gmail.com: Bug#706259: top crashes due to SEGV]

[Jim Warner]

Sorry, I should have CC'd this email at the time of sending.


Begin forwarded message:

 From: Jim Warner james.war...@comcast.net
 Subject: Re: [amos...@gmail.com: Bug#706259: top crashes due to SEGV]
 Date: April 29, 2013 8:34:56 AM CDT
 To: amos...@gmail.com
 Cc: Craig Small csm...@enc.com.au
 
 Hi Amos,
 
 Craig Small (the Debian procps maintainer) sent your bug report to me (the 
 top author).
 
 You can send me the dumps if you wish, but I'm 99.8% certain the problem has 
 already been identified and fixed.  The problem originates in our library and 
 so can affect multiple programs.
 
 A similar abend surfaced under Fedora but involved the ps program.  This link 
 has a little more information and refers to the specific patch.
 https://bugzilla.redhat.com/show_bug.cgi?id=951391
 
 If you would rather not wait for release 3.3.8, the most recent sources can 
 be obtained using:
 git clone git://gitorious.org/procps/procps.git procps
 
 Then the following commands would create and install the latest version.
 
 cd procps
 ./autogen.sh
 .configure
 make
 sudo make install
 
 By default, they'll be installed to /usr/local on your Archlinux system and 
 so shouldn't interfere with the existing 3.3.7 versions.
 
 Regards,
 Jim
 
 
 On Apr 28, 2013, at 5:33 PM, Craig Small csm...@enc.com.au wrote:
 
 Hi Jim,
 I got this email from the Debian Bug Tracking System. Not a lot
 of detail in it but he has coredumps if that helps.
 
 To reply back, I'd prefer if you CC 706...@bugs.debian.org too so the
 tracker has a record of it. I receive all emails from that alias too.
 
 - Craig
 
 - Forwarded message from Amos Onn amos...@gmail.com -
 
 Date: Sat, 27 Apr 2013 14:30:58 +0300
 From: Amos Onn amos...@gmail.com
 To: sub...@bugs.debian.org
 Subject: Bug#706259: top crashes due to SEGV
 Authentication-Results: mail.enc.com.au; dkim=fail reason=verification 
 failed;
  insecure key header.d=gmail.com header.i=@gmail.com header.b=GAkibCX2;
  dkim-adsp=none (insecure policy); dkim-atps=neutral
 X-DSPAM-Result: Innocent
 
  Package: procps
  Version: 3.3.7-1
 
  signal 11 (SEGV) was caught by top, please
  see http://www.debian.org/Bugs/Reporting
  zsh: segmentation fault (core dumped)  top
 
  I run top for a long time in the background, and once in a while, when I
  go to check it up, I see it has crashed with this message. I suspect it
  might have to do with sending my system to sleep (suspend).
 
  I run on ArchLinux, kernel 3.8.4-1-ARCH, x86_64 GNU/Linux.
  I use glibc 2.17-5, ncurses 5.9-5, and systemd 202-2.
 
  I have coredumps for this - reasonable place to upload them?
 
 - End forwarded message -
 
 -- 
 Craig Small VK2XLZ   http://enc.com.au/  csmall at : enc.com.au
 Debian GNU/Linux http://www.debian.org/  csmall at : debian.org
 GPG fingerprint: 5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5
 


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#707648: top: number formatting

[Jim Warner]

Hi Pierre,

I wanted to let you know that with a soon to be released procps-ng-3.3.8 the 
top %CPU and %MEM columns will be returned to their former widths and 
precision.  With yours as the most recent objection, I became convinced that 
idea was *not* one of my best.

As for the actual memory columns, they'll retain their 3.3.6 widths but there's 
a provision that may make them more to your liking.  With release 3.3.6 both 
the Summary Area and Task Area memory fields were made scalable.

The 'E' toggle deals with the Summary fields and the 'e' toggle affects the 
Task fields.  Whatever base value is preferred can be preserved in the .toprc 
file, should you choose to use the 'W' command.

Those slightly increased widths mean displayed values have a better chance of 
not being scaled.  That, in turn, can be important to the release 3.3.7 'Other 
filter' feature.  That extremely powerful top enhancement takes the form of two 
new commands ('O'/'o').

Anyway, thanks to your bug report neither of the above provisions is written in 
stone.  Both the percentage and memory fields can be controlled with these 
./configure options for those willing to rebuild the source.
--enable-wide-percent
--disable-wide-memory

The most recent source is available here:
http://sourceforge.net/projects/procps-ng/files/Production/


Regards,
Jim


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org