Bug 691347

Summary: [RFE] Avoid exhausting resources when building a program with a large .bss section
Product: Red Hat Enterprise Linux 6 Reporter: J.H.M. Dassen (Ray) <rdassen>
Component: binutilsAssignee: Nick Clifton <nickc>
Status: CLOSED DUPLICATE QA Contact: qe-baseos-tools-bugs
Severity: medium Docs Contact:
Priority: medium    
Version: 6.1CC: awiggins, jan.kratochvil, law, rbinkhor, spoyarek
Target Milestone: rcKeywords: FutureFeature, Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-17 21:23:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 607248, 756082    
Attachments:
Description Flags
Sample program that demonstrates the problem none

Description J.H.M. Dassen (Ray) 2011-03-28 10:13:44 UTC
2. What is the nature and description of the request?

The customer has observed that 'ld' can sometimes cause the system to spend a
large amount of time and resources (to the point of preventing any
interactivity with the system) while generating the Build ID. This happens in
particular on systems with a large amount of memory when compiling programs
with a large (but not larger than available memory) .bss section.

This request is to add logic to ld to check for this scenario and either avoid
it or print a warning.


3. Why does the customer need this? (List the business requirements here)

There is no specific business impact to the customer; he knows how to avoid the
problem that this solves. However, he feels it would be of potential benefit to
other users to have this functionality implemented.


4. How would the customer like to achieve this? (List the functional
requirements here)

This only applies when --build-id is not explicitly set. ld would attempt to
detect when generating the sha1sum for the Build ID would take a long time and
be very resource-intensive. It would then either:

4a. Abort the linking and require passing an explicit option to continue
(either setting --build-id explicitly or passing an option such as
--force-build-id)

4b. Leave the .bss section out of the Build ID computation. This has the
advantage of being easier to detect in code - we could simply hard-code a
threshold size for the .bss section, and if it exceeds this size, do not
include in it the sha1sum input.

4c. Continue normally, but print a warning that the compilation may cause
hangs/performance issues/take a long time. Include information about overriding
with --build-id in this warning.


5. For each functional requirement listed in question 4, specify how Red Hat
and the customer can test to confirm the requirement is successfully
implemented.

A test program that creates an arbitrarily-sized bss section is already
attached to the ticket. We could use this program to confirm that the behavior
is triggered under the right circumstances. Additionally, the customer could
verify that his machine no longer experiences hangs when compiling without the
--build-id option.


6. Is there already an existing RFE upstream or in Red Hat bugzilla?

No.


7. How quickly does this need resolved? (desired target release)

No specific release is desired; this is simply something the customer considers
a good idea, and he has an indefinite workaround (--build-id=none)


8. Does this request meet the RHEL Inclusion criteria (please review)

Yes, for either a major or a minor release.


9. List the affected packages

binutils


10. Would the customer be able to assist in testing this functionality if implemented?

Yes

Comment 2 Anna Wiggins 2011-04-12 18:33:54 UTC
Created attachment 491541 [details]
Sample program that demonstrates the problem

Here is a simple test case that shows the problem. To demonstrate the issue, set MEM to something larger than the total avail memory of the system (so that a malloc() call of that size will fail), and compile with:

gcc gcc_test.c -o gcc_test -lm -lc -Dx86_64 -fPIC -m64 -O


Then, set MEM to something smaller than avail memory (so that malloc will succeed), but still very large, and compile again. On RHEL 6, the second compile should take a very long time, and gcc can be observed to be consuming an amount of memory equal to MEM GB.

Comment 5 Jeff Law 2012-03-06 03:56:27 UTC
It was conditionally nakd some time ago due to engineering capacity.  I can't see any way it's going to make 6.3.  I'll go ahead and turn the cond_nak into a full nak and put it on the 6.4 queue.

Comment 6 Jeff Law 2012-04-17 21:23:20 UTC
Marking as duplicate of 809616, which is a public bug.  809616 is scheduled to be resolved for RHEL 6.3.

*** This bug has been marked as a duplicate of bug 809616 ***