Bug 12209 - oldish top core dumps (in its meminfo() function)
Summary: oldish top core dumps (in its meminfo() function)
Status: REJECTED WILL_NOT_FIX
Alias: None
Product: Process Management
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: process_other
URL:
Keywords:
Depends on:
Blocks: 11808
  Show dependency tree
 
Reported: 2008-12-12 14:43 UTC by Rafael J. Wysocki
Modified: 2009-07-08 14:17 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.28-rc8
Tree: Mainline
Regression: Yes


Attachments

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

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