Subject : 2.6.28-rc8: oldish top core dumps (in its meminfo() function)
Submitter : Andreas Mohr <firstname.lastname@example.org>
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.
Verified to still core dump on -rc9 on the same machine.
Seems to be a bug in old versions of top. Please rebuild your top with -g3 and provide traces.
Thanks for your query - further investigation on that machine will have to wait until January.
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).
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?
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