Bug 53702 - top, ps segmentation fault
Summary: top, ps segmentation fault
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: procps   
(Show other bugs)
Version: 7.1
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Alexander Larsson
QA Contact: Aaron Brown
URL: http://www.polarhome.com
Depends On:
TreeView+ depends on / blocked
Reported: 2001-09-15 20:40 UTC by Zoltan Arpadffy
Modified: 2007-04-18 16:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-03-11 16:39:09 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Zoltan Arpadffy 2001-09-15 20:40:28 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90)

Description of problem:
Seems, when number of running processes exceeds some magic number, top, ps 
and other process monitoring programs crashes with segmentation fault. I 
can imagine, that it could be some kernel max value problem, but I could 
not found which one.
Just reboot can help the system... to be managable again.

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

How reproducible:

Steps to Reproduce:
1. log in 500+ users.
2. start few bg processes for each user.
3. if number of running processes are more than 2000-3000 start top.

Actual Results:  Craches with "Segmentation fault" message.

Expected Results:  It should work, because system is without any controll 

Additional info:
Linux gate.polarhome.com 2.4.3-12 #1 Fri Jun 8 15:05:56 EDT 2001 i686 

Comment 1 Jason Corley 2003-03-11 14:20:56 UTC
I am also seeing this on some 7.1 servers I'm running oracle on.  I don't think
the number of processes has to be concurrent either, as all three oracle servers
I administrate (all 7.1) are or have exhibited this behavior (two of them
currently) and the number of running processes is around 200.  I have a top core
dump I can send if that would be useful.  It's about 340k.

Comment 2 Alexander Larsson 2003-03-11 15:05:04 UTC
There is a large chance this has been fixed since 2.0.7. If you can repeat this,
could you please try out the latest version

If it still crashes, can you run it in gdb and get a backtrace when it crashes.

Comment 3 Jason Corley 2003-03-11 16:04:24 UTC
Ok I took your tarball and made an RPM out of it using the 2.0.7-8 SRPM (I
dropped all patches and commented out the X stuff).  I doubt you want it but if
you do I can attach the SRPM or email it to you.  Upgrading to that does indeed
fix the problem.  Any chance this could make an official errata for 7.1 and later?

Comment 4 Alexander Larsson 2003-03-11 16:39:09 UTC
Rawhide already has a 2.0.11 based procps, but that one won't work on 7.x
without a rebuild, so I don't need the srpm.

We don't typically do bugfix errata for old versions like 7.1. Sorry.

Comment 5 Jason Corley 2003-03-11 17:03:04 UTC
If I use the SRPM from rawhide but comment out the NPTL patch, it should work
fine on 7.1 correct (i.e. there's nothing different in the tarball you sent and
the one used in (S)RPM)?

Comment 6 Alexander Larsson 2003-03-12 09:07:25 UTC
Even the NPTL patch shouldn't affect things. Its meant to be backwards compatible.
But yeah, the tarball is the same.

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