Bug 257033 - top(1): Sort by PID broke in 13.0-RELEASE
Summary: top(1): Sort by PID broke in 13.0-RELEASE
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 13.0-RELEASE
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-07-06 21:07 UTC by Kevin Zheng
Modified: 2021-07-09 21:30 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Zheng 2021-07-06 21:07:02 UTC
Sorting processes by PID broke in 13.0-RELEASE.

My uname:
13.0-RELEASE-p3 FreeBSD 13.0-RELEASE-p3 #0: Tue Jun 29 19:46:20 UTC 2021     root@amd64-builder.daemonology.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64

Steps to reproduce:
1. Run 'top'
2. Press 'O', then type 'pid' <ENTER>

top(1) sorts processes correctly on 12.2-RELEASE.

I tried to bisect the issue by building top from as far back as 3be6ef06596a345558f15b91721a9021f3aeefba (May 19 2018) and running on 13.0-RELEASE, but the issue persists. I have not yet tried bisecting further back.
Comment 1 Kevin Zheng 2021-07-06 21:07:34 UTC
(In reply to Kevin Zheng from comment #0)
In "Steps to reproduce," step 2's 'O' should be lowercase 'o'
Comment 2 Mark Millard 2021-07-07 04:12:30 UTC
(In reply to Kevin Zheng from comment #0)

The change was not in top but in r340742
(svn time frame head):

QUOTE
Revision 340742 - Directory Listing 
Modified Wed Nov 21 18:56:15 2018 UTC (2 years, 7 months ago) by mjg
proc: implement pid hash locks and an iterator

forks, exits and waits are frequently stalled during poudriere -j 128 runs
due to killpg and process list exports performed for each package.

Both uses take the allproc lock. The latter case can be modified to iterate
over the hash with finer grained locking instead.

Reviewed by:	kib
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D17817
END QUOTE

Top was not adjusted to deal with the consequences. But bisecting
top itself will do any good finding the change that lead to the
behavioral difference.

There was a review for an update to top that was never adopted:

https://reviews.freebsd.org/D18658
Comment 3 Mark Millard 2021-07-07 08:06:20 UTC
(In reply to Mark Millard from comment #2)

Missing word "not", so: "will *not* do any good finding"
Comment 4 Kevin Zheng 2021-07-07 14:56:14 UTC
(In reply to Mark Millard from comment #2)
Thanks for the reply and explanation. Any chance we can get the author to un-abandon the review on Phabricator?
Comment 5 Mark Millard 2021-07-07 15:24:28 UTC
(In reply to Kevin Zheng from comment #4)

You are welcome.

I do not seem to be the right person to ask about any
abandonment status change for:

https://reviews.freebsd.org/D18658