Bug 12209

Summary: oldish top core dumps (in its meminfo() function)
Product: Process Management Reporter: Rafael J. Wysocki (rjw)
Component: OtherAssignee: process_other
Status: REJECTED WILL_NOT_FIX    
Severity: normal CC: alan, andi
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.28-rc8 Subsystem:
Regression: Yes Bisected commit-id:
Bug Depends on:    
Bug Blocks: 11808    

Description Rafael J. Wysocki 2008-12-12 14:43:23 UTC 
Subject    : 2.6.28-rc8: oldish top core dumps (in its meminfo() function)
Submitter  : Andreas Mohr <andi@lisas.de>
Date       : 2008-12-12 18:49
References : http://marc.info/?l=linux-kernel&m=122910784006472&w=4
References : http://marc.info/?l=linux-kernel&m=122907511319288&w=4

This entry is being used for tracking a regression from 2.6.27.  Please don't
close it until the problem is fixed in the mainline.
Comment 1 Andreas Mohr 2008-12-19 05:49:47 UTC 
Verified to still core dump on -rc9 on the same machine.
Comment 2 Alan 2008-12-22 09:38:10 UTC 
Seems to be a bug in old versions of top. Please rebuild your top with -g3 and provide traces.
Comment 3 Andreas Mohr 2008-12-23 07:42:35 UTC 
Thanks for your query - further investigation on that machine will have to wait until January.
Comment 4 Andreas Mohr 2009-03-10 11:28:19 UTC 
I had trouble finding sources of this version. Finally found procps-2.0.17-5.src.rpm.
Extracted it, applied most (except for selinux) patches.
Ran make, managed to build fully (despite convoluted system dependencies).
Ran ./top, crashed.
With LD_LIBRARY_PATH=proc ./top, it worked. Humm.
IOW, the locally built libproc.so.2.0.17 is ok (probably due to referencing sufficiently current system headers as opposed to the original RHEL3 build?), as opposed to the system one.
Will try with selinux patch now (need to install selinux devel package for headers).
Thanks!
Comment 5 Andreas Mohr 2009-03-10 11:40:14 UTC 
Retrying with selinux headers doesn't make much sense methinks, since this is a non-selinux system.

It might prove successful to rebuild procps-2.0.17-5 using kernel headers just slightly older than the breakage, I think (and then hopefully have the newly built libprocps fail - to expose some suspected header incompatibility). Should I do this? What else could be done?
Comment 6 Alan 2009-07-08 14:17:01 UTC 
Not sure - but there are various other known bugs with the ancient top/proc stuff having checked the history a bit further, including known cases where it dumps with lots of processors. Seems to be down to user space bugs not to a kernel regression

So closing as WONTFIX