Harden_all_packages_with_position-independent_code + guile modules

[Ralf Corsepius]

On 03/13/2015 01:58 PM, Kevin Fenzi wrote:
> On Fri, 13 Mar 2015 07:46:04 +0100
> Ralf Corsepius <rc040203 at freenet.de> wrote:
>
>> On 03/12/2015 05:06 PM, Ralf Corsepius wrote:
>>
>>> Well, all I can say, building rawhide packages (esp. C++) seems to
>>> have evolved into a lottery and rendered working one Fedora
>>> packages into an adventure.
>>>
>>> E.g. I am facing packages which one day build, but fail to build the
>>> other day. Today, I have been facing a package which builds in local
>>> rawhide mocks, but fails in official koji.
>>
>> Let me provide some facts, as they happened to me, yesterday
>> (2015-03-12): Trying to build k3d[1] for rawhide
>>
>>
>> - ca. 10:00 UTC: local x86_64-mockbuild succeeds
>>
>> - 10:15 UTC: Building in koji
>>     koji fails on x86_64: c++: internal compiler error: Killed
>> (program cc1plus)
>>     https://koji.fedoraproject.org/koji/taskinfo?taskID=9208659
>
> builder: buildhw-06
>
> Mar 12 10:22:17 buildhw-06.phx2.fedoraproject.org kernel: Out of memory: Kill process 10227 (cc1plus) score 29 or sacrifice child
> Mar 12 10:22:17 buildhw-06.phx2.fedoraproject.org kernel: Killed process 10227 (cc1plus) total-vm:635536kB, anon-rss:578384kB, file-rss:17300kB
> Mar 12 10:22:17 buildhw-06.phx2.fedoraproject.org kernel: cc1plus: page
> allocation failure: order:0, mode:0x280da
>
>> - 10:36 UTC: Presuming a temporary hickup, retrying koji
>>     koji fails on x86_64: c++: internal compiler error: Killed
>> (program cc1plus)
>>     https://koji.fedoraproject.org/koji/taskinfo?taskID=9208790
>
> builder: buildhw-06 again
>
> Mar 12 10:43:46 buildhw-06.phx2.fedoraproject.org kernel: Out of memory: Kill process 13650 (cc1plus) score 29 or sacrifice child
> Mar 12 10:43:46 buildhw-06.phx2.fedoraproject.org kernel: Killed process 13650 (cc1plus) total-vm:647752kB, anon-rss:594536kB, file-rss:12628kB
> Mar 12 10:43:57 buildhw-06.phx2.fedoraproject.org kernel: as invoked
> oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
>
> ...snip...
>
>> ?!?
>
> My conclusion is that gcc5 is at least sometimes using a lot more
> memory than older versions.
I haven't noticed a significant increase in memory usage in my local 
mock builds, but I haven't tried to investigate.

> Perhaps reducing smp_mflags could help?
Dunno ;)

> buildhw boxes have 20GB of memory and 16CPUs... so perhaps 16 threads
> is causing it to hit OOM much more often than in the past?
 >
> buildvm boxes have 10GB of memory, but only 4 (faster) cpus.
> arm boxes have 4GB of memory and 4 cpus.
Does this explain why my yesterday's scratch-builds didn't fail but 
"real" builds failed?

Does this explain why "real" builds failed yesterday but succeed today? 
Did you change something about this configuration or has something 
related to g++ changed within the last 24hrs?

... too many unknowns for my taste.

Ralf