Bug 109704 - ps -m doesn't show threads
Summary: ps -m doesn't show threads
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: procps (Show other bugs)
(Show other bugs)
Version: 1
Hardware: i686 Linux
medium
medium
Target Milestone: ---
Assignee: Alexander Larsson
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-11-11 03:03 UTC by Need Real Name
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-11-17 02:07:12 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Need Real Name 2003-11-11 03:03:24 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5)
Gecko/20031007 Firebird/0.7

Description of problem:
ps -m no longer shows threads. It did in RedHat 9.

It looks to me like the /proc entries for the thread are missing?
Since I can't tell what PID they have, it's hard to tell, but assuming
the next PID would have been allocated, there's no entry for it.

On the other hand, if the (numerically) next entry in /proc (which
isn't PPID + 1) _is_ the thread, it's weirdly formed - the exe "link"
doesn't go anywhere, for example.

Run the following python example and use ps -m. On RedHat 9, you'll
see two threads, on Fedora Core 1, just the parent.

-----

import threading, time

def test():
  while 1:
    time.sleep(10)

threading.Thread(target = test).start()

-----

Version-Release number of selected component (if applicable):
procps-2.0.17-1

How reproducible:
Always

Comment 1 Need Real Name 2003-11-17 02:07:12 UTC
It appears the problem was that I'd built procps-2.0.17-1 on RH9 (to
get the slabinfo commands) and that build was somehow broken against
Fedora 1.

It's probably a bug in the procps build scripts (like it detects
kernel version at compile time rather than run time), but it's not
this bug.


Note You need to log in before you can comment on or make changes to this bug.