Bug 487848

Summary: gcc crashes building openvrml
Product: [Fedora] Fedora Reporter: Braden McDaniel <braden>
Component: openvrmlAssignee: Braden McDaniel <braden>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: low    
Version: rawhideCC: braden, jakub
Target Milestone: ---   
Target Release: ---   
Hardware: ppc64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-03-23 17:40:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Build log none

Description Braden McDaniel 2009-02-28 09:11:21 UTC 
Description of problem:
I'm seeing a crash in gcc when trying to rebuild the openvrml package.  ppc platforms churned a good deal longer than others before ppc64 finally died.  32-bit ppc seemed to be in the same spot in the build when koji shut it down.  Possibly some problem in gcc is causing it to churn and grow in memory at this point in the build and the OOM killer was triggered on ppc64 first.

Version-Release number of selected component (if applicable):
4.4.0-0.21.1
Comment 1 Braden McDaniel 2009-02-28 09:12:04 UTC 
Created attachment 333594 [details]
Build log
Comment 2 Jakub Jelinek 2009-03-04 11:21:43 UTC 
Both browser and vrml97node are excessively huge, but both compile in under 2GB on ppc64 for me.  If the ppc{,64} koji buildboxes don't have enough, perhaps you shouldn't use %{_smp_mflags}, as when you build both vrml97node and browser at once, you need almost 2GB+2GB of RAM.  Perhaps a hack like:
if [ `free -b | awk '/^Mem:/{print $2}'` -gt 4000000000 ]; then
make %{_smp_mflags}
else
# vrml97node.cpp and browser.cpp are huge and need a lot of RAM.
make
fi
Comment 3 Braden McDaniel 2009-03-04 18:50:05 UTC 
Okay... If this is just "normal" memory starvation, feel free to close this.

I'm aware of the problems with the magnitude of those files; and a (not-too-distant) future release of OpenVRML addresses this. In the meantime, that hack is probably the right solution. Thanks.
Comment 4 Braden McDaniel 2009-03-23 17:40:35 UTC 
OpenVRML's specfile now includes such a check for the build host's installed RAM.