Bug 487848 - gcc crashes building openvrml
gcc crashes building openvrml
Product: Fedora
Classification: Fedora
Component: openvrml (Show other bugs)
ppc64 Linux
low Severity urgent
: ---
: ---
Assigned To: Braden McDaniel
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-02-28 04:11 EST by Braden McDaniel
Modified: 2009-03-23 13:40 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-03-23 13:40:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Build log (452.62 KB, text/plain)
2009-02-28 04:12 EST, Braden McDaniel
no flags Details

  None (edit)
Description Braden McDaniel 2009-02-28 04:11:21 EST
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):
Comment 1 Braden McDaniel 2009-02-28 04:12:04 EST
Created attachment 333594 [details]
Build log
Comment 2 Jakub Jelinek 2009-03-04 06:21:43 EST
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}
# vrml97node.cpp and browser.cpp are huge and need a lot of RAM.
Comment 3 Braden McDaniel 2009-03-04 13:50:05 EST
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 13:40:35 EDT
OpenVRML's specfile now includes such a check for the build host's installed RAM.

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