Daily builds of Java packages fail: "Could not reserve enough space for object heap"

[Philip Muškovac]

Some daily builds takes bzr a huge amount to check out and this fails on builders which have less memory.

I'm getting seemingly random build failures for
https://code.launchpad.net/~neon/+recipe/project-neon-kdesdk

---
Setting up ca-certificates-java (20100412) ...
creating /etc/ssl/certs/java/cacerts...
Could not create the Java virtual machine.
  error adding brasil.gov.br/brasil.gov.br.crt
  error adding cacert.org/cacert.org.crt
  error adding debconf.org/ca.crt
  error adding gouv.fr/cert_igca_dsa.crt
  error adding gouv.fr/cert_igca_rsa.crt
  error adding mozilla/ABAecom_=sub.__Am._Bankers_Assn.=_Root_CA.crt
  error adding mozilla/AOL_Time_Warner_Root_Certification_Authority_1.crt
  error adding mozilla/AOL_Time_Warner_Root_Certification_Authority_2.crt
  error adding mozilla/AddTrust_External_Root.crt
  error adding mozilla/AddTrust_Low-Value_Services_Root.crt
  error adding mozilla/AddTrust_Public_Services_Root.crt
  error adding mozilla/AddTrust_Qualified_Certificates_Root.crt
  error adding mozilla/America_Online_Root_Certification_Authority_1.crt
  error adding mozilla/America_Online_Root_Certification_Authority_2.crt
  error adding mozilla/Baltimore_CyberTrust_Root.crt
  error adding mozilla/COMODO_Certification_Authority.crt
  error adding mozilla/COMODO_ECC_Certification_Authority.crt
  error adding mozilla/Camerfirma_Chambers_of_Commerce_Root.crt
  error adding mozilla/Camerfirma_Global_Chambersign_Root.crt
  error adding mozilla/Certplus_Class_2_Primary_CA.crt
  error adding mozilla/Certum_Root_CA.crt
  error adding mozilla/Comodo_AAA_Services_root.crt
  error adding mozilla/Comodo_Secure_Services_root.crt
  error adding mozilla/Comodo_Trusted_Services_root.crt
  error adding mozilla/DST_ACES_CA_X6.crt
  error adding mozilla/DST_Root_CA_X3.crt
  error adding mozilla/DigiCert_Assured_ID_Root_CA.crt
  error adding mozilla/DigiCert_Global_Root_CA.crt
  error adding mozilla/DigiCert_High_Assurance_EV_Root_CA.crt
  error adding mozilla/DigiNotar_Root_CA.crt
  error adding mozilla/Digital_Signature_Trust_Co._Global_CA_1.crt
  error adding mozilla/Digital_Signature_Trust_Co._Global_CA_2.crt
  error adding mozilla/Digital_Signature_Trust_Co._Global_CA_3.crt
  error adding mozilla/Digital_Signature_Trust_Co._Global_CA_4.crt
  error adding mozilla/Entrust.net_Global_Secure_Personal_CA.crt
  error adding mozilla/Entrust.net_Global_Secure_Server_CA.crt
  error adding mozilla/Entrust.net_Premium_2048_Secure_Server_CA.crt
  error adding mozilla/Entrust.net_Secure_Personal_CA.crt
  error adding mozilla/Entrust.net_Secure_Server_CA.crt
  error adding mozilla/Entrust_Root_Certification_Authority.crt
  error adding mozilla/Equifax_Secure_CA.crt
  error adding mozilla/Equifax_Secure_Global_eBusiness_CA.crt
  error adding mozilla/Equifax_Secure_eBusiness_CA_1.crt
  error adding mozilla/Equifax_Secure_eBusiness_CA_2.crt
  error adding mozilla/Firmaprofesional_Root_CA.crt
  error adding mozilla/GTE_CyberTrust_Global_Root.crt
  error adding mozilla/GTE_CyberTrust_Root_CA.crt
  error adding mozilla/GeoTrust_Global_CA.crt
  error adding mozilla/GeoTrust_Global_CA_2.crt
  error adding mozilla/GeoTrust_Primary_Certification_Authority.crt
  error adding mozilla/GeoTrust_Universal_CA.crt
  error adding mozilla/GeoTrust_Universal_CA_2.crt
  error adding mozilla/GlobalSign_Root_CA.crt
  error adding mozilla/GlobalSign_Root_CA_-_R2.crt
  error adding mozilla/Go_Daddy_Class_2_CA.crt
  error adding mozilla/IPS_CLASE1_root.crt
  error adding mozilla/IPS_CLASE3_root.crt
  error adding mozilla/IPS_CLASEA1_root.crt
  error adding mozilla/IPS_CLASEA3_root.crt
  error adding mozilla/IPS_Chained_CAs_root.crt
  error adding mozilla/IPS_Servidores_root.crt
  error adding mozilla/IPS_Timestamping_root.crt
  error adding mozilla/NetLock_Business_=Class_B=_Root.crt
  error adding mozilla/NetLock_Express_=Class_C=_Root.crt
  error adding mozilla/NetLock_Notary_=Class_A=_Root.crt
  error adding mozilla/NetLock_Qualified_=Class_QA=_Root.crt
  error adding mozilla/Network_Solutions_Certificate_Authority.crt
  error adding mozilla/QuoVadis_Root_CA.crt
  error adding mozilla/QuoVadis_Root_CA_2.crt
  error adding mozilla/QuoVadis_Root_CA_3.crt
  error adding mozilla/RSA_Root_Certificate_1.crt
  error adding mozilla/RSA_Security_1024_v3.crt
  error adding mozilla/RSA_Security_2048_v3.crt
  error adding mozilla/SecureTrust_CA.crt
  error adding mozilla/Secure_Global_CA.crt
  error adding mozilla/Security_Communication_Root_CA.crt
  error adding mozilla/Sonera_Class_1_Root_CA.crt
  error adding mozilla/Sonera_Class_2_Root_CA.crt
  error adding mozilla/Staat_der_Nederlanden_Root_CA.crt
  error adding mozilla/Starfield_Class_2_CA.crt
  error adding mozilla/StartCom_Certification_Authority.crt
  error adding mozilla/StartCom_Ltd..crt
  error adding mozilla/SwissSign_Gold_CA_-_G2.crt
  error adding mozilla/SwissSign_Platinum_CA_-_G2.crt
  error adding mozilla/SwissSign_Silver_CA_-_G2.crt
  error adding mozilla/Swisscom_Root_CA_1.crt
  error adding mozilla/TC_TrustCenter__Germany__Class_2_CA.crt
  error adding mozilla/TC_TrustCenter__Germany__Class_3_CA.crt
  error adding mozilla/TDC_Internet_Root_CA.crt
  error adding mozilla/TDC_OCES_Root_CA.crt
  error adding mozilla/TURKTRUST_Certificate_Services_Provider_Root_1.crt
  error adding mozilla/TURKTRUST_Certificate_Services_Provider_Root_2.crt
  error adding mozilla/Taiwan_GRCA.crt
  error adding mozilla/Thawte_Personal_Basic_CA.crt
  error adding mozilla/Thawte_Personal_Freemail_CA.crt
  error adding mozilla/Thawte_Personal_Premium_CA.crt
  error adding mozilla/Thawte_Premium_Server_CA.crt
  error adding mozilla/Thawte_Server_CA.crt
  error adding mozilla/Thawte_Time_Stamping_CA.crt
  error adding mozilla/UTN-USER_First-Network_Applications.crt
  error adding mozilla/UTN_DATACorp_SGC_Root_CA.crt
  error adding mozilla/UTN_USERFirst_Email_Root_CA.crt
  error adding mozilla/UTN_USERFirst_Hardware_Root_CA.crt
  error adding mozilla/ValiCert_Class_1_VA.crt
  error adding mozilla/ValiCert_Class_2_VA.crt
  error adding mozilla/VeriSign_Class_3_Public_Primary_Certification_Authority_-_G5.crt
  error adding mozilla/Verisign_Class_1_Public_Primary_Certification_Authority.crt
  error adding mozilla/Verisign_Class_1_Public_Primary_Certification_Authority_-_G2.crt
  error adding mozilla/Verisign_Class_1_Public_Primary_Certification_Authority_-_G3.crt
  error adding mozilla/Verisign_Class_2_Public_Primary_Certification_Authority.crt
  error adding mozilla/Verisign_Class_2_Public_Primary_Certification_Authority_-_G2.crt
  error adding mozilla/Verisign_Class_2_Public_Primary_Certification_Authority_-_G3.crt
  error adding mozilla/Verisign_Class_3_Public_Primary_Certification_Authority.crt
  error adding mozilla/Verisign_Class_3_Public_Primary_Certification_Authority_-_G2.crt
  error adding mozilla/Verisign_Class_3_Public_Primary_Certification_Authority_-_G3.crt
  error adding mozilla/Verisign_Class_4_Public_Primary_Certification_Authority_-_G2.crt
  error adding mozilla/Verisign_Class_4_Public_Primary_Certification_Authority_-_G3.crt
  error adding mozilla/Verisign_RSA_Secure_Server_CA.crt
  error adding mozilla/Verisign_Time_Stamping_Authority_CA.crt
  error adding mozilla/Visa_International_Global_Root_2.crt
  error adding mozilla/Visa_eCommerce_Root.crt
  error adding mozilla/WellsSecure_Public_Root_Certificate_Authority.crt
  error adding mozilla/Wells_Fargo_Root_CA.crt
  error adding mozilla/XRamp_Global_CA_Root.crt
  error adding mozilla/beTRUSTed_Root_CA-Baltimore_Implementation.crt
  error adding mozilla/beTRUSTed_Root_CA.crt
  error adding mozilla/beTRUSTed_Root_CA_-_Entrust_Implementation.crt
  error adding mozilla/beTRUSTed_Root_CA_-_RSA_Implementation.crt
  error adding mozilla/thawte_Primary_Root_CA.crt
  error adding signet.pl/signet_ca1_pem.crt
  error adding signet.pl/signet_ca2_pem.crt
  error adding signet.pl/signet_ca3_pem.crt
  error adding signet.pl/signet_ocspklasa2_pem.crt
  error adding signet.pl/signet_ocspklasa3_pem.crt
  error adding signet.pl/signet_pca2_pem.crt
  error adding signet.pl/signet_pca3_pem.crt
  error adding signet.pl/signet_rootca_pem.crt
  error adding signet.pl/signet_tsa1_pem.crt
  error adding spi-inc.org/spi-ca-2003.crt
  error adding spi-inc.org/spi-cacert-2008.crt
  error adding telesec.de/deutsche-telekom-root-ca-2.crt
failed (VM used: java-6-openjdk).
dpkg: error processing ca-certificates-java (--configure):
 subprocess installed post-installation script returned error exit status 1
Setting up openjdk-6-jre-headless (6b20-1.9.2-0ubuntu2) ...
No apport report written because MaxReports is reached already
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/bin/java to provide /usr/bin/java (java) in auto mode.
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/bin/keytool to provide /usr/bin/keytool (keytool) in auto mode.
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/bin/pack200 to provide /usr/bin/pack200 (pack200) in auto mode.
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/bin/rmid to provide /usr/bin/rmid (rmid) in auto mode.
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/bin/rmiregistry to provide /usr/bin/rmiregistry (rmiregistry) in auto mode.
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/bin/unpack200 to provide /usr/bin/unpack200 (unpack200) in auto mode.
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/bin/orbd to provide /usr/bin/orbd (orbd) in auto mode.
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/bin/servertool to provide /usr/bin/servertool (servertool) in auto mode.
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/bin/tnameserv to provide /usr/bin/tnameserv (tnameserv) in auto mode.
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/lib/jexec to provide /usr/bin/jexec (jexec) in auto mode.
Could not create the Java virtual machine.
Error occurred during initialization of VM
Could not reserve enough space for object heap
ignoring dump failure
---

This never failed yet when I try to build in a PPA and I can't reproduce it in a local chroot either.
The builds that failed so far:
https://code.launchpad.net/~neon/+recipe/project-neon-kdesdk/+build/12437
https://code.launchpad.net/~neon/+recipe/project-neon-kdesdk/+build/12332
https://code.launchpad.net/~neon/+recipe/project-neon-kdesdk/+build/12187
https://code.launchpad.net/~neon/+recipe/project-neon-kdesdk/+build/11858
https://code.launchpad.net/~neon/+recipe/project-neon-kdesdk/+build/11857
https://code.launchpad.net/~neon/+recipe/project-neon-kdesdk/+build/11654
https://code.launchpad.net/~neon/+recipe/project-neon-kdesdk/+build/11239
https://code.launchpad.net/~neon/+recipe/project-neon-kdesdk/+build/11126
https://code.launchpad.net/~neon/+recipe/project-neon-kdesdk/+build/10971
https://code.launchpad.net/~neon/+recipe/project-neon-kdesdk/+build/10663

[Tim Penhey (thumper)]

Very weird. Perhaps best solved with a question. Does this work locally for you? Could it be a bad dependency?

[Tim Penhey (thumper)]

Actually, just caught the end of the description. Local chroot build works? Have you tried with bzr-builder? I'm wondering if it is doing something weird.

[Philip Muškovac (yofel)]

I tried several builds in pbuilder, and so far not even one PPA build has failed, this only fails in the recipe buildds, and I doubt bzr-builder has anything to do with it since it doesn't even get to that.

[Robert Collins (lifeless)]

Lamont, any idea?

[Andrew Ross (rockclimb)]

In case it helps, earlier in the log (at least in my case) is this error, which makes it look like it might be a memory limit issue:

Setting up openjdk-6-jre-headless (6b20-1.9.7-0ubuntu1) ...
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/bin/java to provide /usr/bin/java (java) in auto mode.
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/bin/keytool to provide /usr/bin/keytool (keytool) in auto mode.
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/bin/pack200 to provide /usr/bin/pack200 (pack200) in auto mode.
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/bin/rmid to provide /usr/bin/rmid (rmid) in auto mode.
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/bin/rmiregistry to provide /usr/bin/rmiregistry (rmiregistry) in auto mode.
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/bin/unpack200 to provide /usr/bin/unpack200 (unpack200) in auto mode.
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/bin/orbd to provide /usr/bin/orbd (orbd) in auto mode.
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/bin/servertool to provide /usr/bin/servertool (servertool) in auto mode.
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/bin/tnameserv to provide /usr/bin/tnameserv (tnameserv) in auto mode.
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/lib/jexec to provide /usr/bin/jexec (jexec) in auto mode.
Could not create the Java virtual machine.
Error occurred during initialization of VM
Could not reserve enough space for object heap
ignoring dump failure

[Andrew Ross (rockclimb)]

This is still happening, for example in https://launchpadlibrarian.net/72367061/buildlog.txt.gz - is there any news on tracking it down? The first sign of a problem appears in the logs as follows:

Setting up openjdk-6-jre-headless (6b20-1.9.7-0ubuntu1) ...
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/bin/java to provide /usr/bin/java (java) in auto mode.
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/bin/keytool to provide /usr/bin/keytool (keytool) in auto mode.
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/bin/pack200 to provide /usr/bin/pack200 (pack200) in auto mode.
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/bin/rmid to provide /usr/bin/rmid (rmid) in auto mode.
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/bin/rmiregistry to provide /usr/bin/rmiregistry (rmiregistry) in auto mode.
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/bin/unpack200 to provide /usr/bin/unpack200 (unpack200) in auto mode.
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/bin/orbd to provide /usr/bin/orbd (orbd) in auto mode.
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/bin/servertool to provide /usr/bin/servertool (servertool) in auto mode.
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/bin/tnameserv to provide /usr/bin/tnameserv (tnameserv) in auto mode.
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/lib/jexec to provide /usr/bin/jexec (jexec) in auto mode.
Could not create the Java virtual machine.
Error occurred during initialization of VM
Could not reserve enough space for object heap
ignoring dump failure
Setting up openjdk-6-jre-lib (6b20-1.9.7-0ubuntu1) ...

[Stefan Handschuh (handschuh)]

Is there any progress on this issue?

I am also experiencing this bug which only seems to be due to
   Could not reserve enough space for object heap

[Stefan Handschuh (handschuh)]

@Philip:
I think, it is possible to work around this in your package by depending on the gcj explicitly such that the default-jdk won't be installed. This "solved" the issue for my project but of course this is no general workaround and only works if the packages have dependencies to java5-runtime (since gcj does not provide java6-runtime).

[Akos Kemives (akoskm)]

Hi!
Tested my recipe locally, everything fine, the source package was built. However I'm constantly facing with this error when requesting builds for my sources on launchpad.
https://launchpadlibrarian.net/81520575/buildlog.txt.gz
Any progress about this bug?

[Julian Edwards (julian-edwards)]

Not all the builders have the same amount of memory. If a build gets particularly hungry it'll randomly fail as described. I'm not sure this is a bug in the buildd, really, but I'll leave it as a placeholder for now.

[Akos Kemives (akoskm)]

So this means I can randomly build my packages in launcphad. Is there any other way which is more productive and less depends on randomness?

[Andrew Ross (rockclimb)]

It's odd that the errors only every occur when building source packages from recipes, never when actually compiling the binary packages. Do the recipe builders have a lot less memory assigned?

[Philip Muškovac (yofel)]

On a positive note, this doesn't seem to be happening in oneiric anymore. But I still get recipe failures for natty.

[Akos Kemives (akoskm)]

Unfortunately its all the same.. Just tried to build something and got the same error like before: https://launchpadlibrarian.net/83465484/buildlog.txt.gz.

[Francis J. Lacoste (flacoste)]

A newer version of bzr in the builders would reduce the memory foot print required (in progress, tracked in RT #46345)

[Martin Pool (mbp)]

It looks like the deployment of this was buggy (causing bug 884516) and the setup on qastaging was not reproduced on lpnet.

We have gone back to bzr 2.4.0 on lpnet, as used last week.

We will try again to deploy the bzr* updates on qastaging, test it properly, then again deploy to lpnet.

[Martin Pool (mbp)]

@Francis, there seem to be two totally separate problems here:

One is the Java error "Could not reserve enough space for object heap" which is that Java can't start in the 1.5GB or whatever the builder vms have. I don't know how that could be fixed other than by giving them more memory or tweaking the build script to cope with less memory or to use a different jvm as suggested above. That's what this bug 693524 seems to be mostly about.

The other is what happened in <https://answers.launchpad.net/launchpad/+question/173422> with "bzr: out of memory" which is what I hope will be fixed soon by this rollout. I have locally tested bzr 2.4 and current bzr-builder in a 1GB ulimit and they did successfully build the projectneon recipe. When that rollout completes this should be fixed. That's bug 746822.

As far as I know this bug has nothing to do with bzr (my comment #16 was misplaced) and this does not affect linaro.

[Julian Edwards (julian-edwards)]

A good question at this point would be, exactly how much memory does the Java runtime need to start during the build? The builders have 1.5Gb of memory already.

[Jelmer Vernooij (jelmer)]

note that the buildrecipe script sets a (soft) maximum virtual memory size of 1Gb using rlimit (lib/canonical/buildd/buildrecipe line 210). That's not all that much for java as far as I know.

Is there a particular reason we need this for recipe builds? We don't seem to have it for non-recipe builds.

[Robert Collins (lifeless)]

The *bzr* part kept thrashing machines, so a limit was installed to
make it fail faster.

[Jelmer Vernooij (jelmer)]

I realize that, but is that still necessary? The memory usage on the bzr side of things should now have been addressed.

[Robert Collins (lifeless)]

2011/11/16 Jelmer Vernooij <email address hidden>:
> I realize that, but is that still necessary? The memory usage on the bzr
> side of things should now have been addressed.

belts and bracers.

[Jelmer Vernooij (jelmer)]

Those belts and bracers should apply to non-recipe builds too. As far as I know they don't have such a limit.

What about using RLIMIT_DATA rather than RLIMIT_AS?

[Robert Collins (lifeless)]

2011/11/18 Jelmer Vernooij <email address hidden>:
> Those belts and bracers should apply to non-recipe builds too. As far as
> I know they don't have such a limit.

Ideally they would. However apparently the distro depends on
swap-thrashing ARM machines to let big packages build. This seems
crazy to me, but in those cases we're not running LP code, we're
running arbitrary end user code that can do nuts things. I want to
revisit this but its not the top of the pile.

> What about using RLIMIT_DATA rather than RLIMIT_AS?

What will that do for us?

-Rob

[William Grant (wgrant)]

RLIMIT_DATA doesn't work on modern systems due to allocation by mmap().

[Andrew Ross (rockclimb)]

I'm still getting these failures. I can reproduce locally with "ulimit -v 1048576", and indeed with "ulimit -v 2097152". It worked fine with "ulimit -v 4194304". Do we know what the current limit is?

[Andrew Ross (rockclimb)]

Oh, and I still don't know why sometimes it works and sometimes it doesn't...

[Morty (morty)]

I have no real understanding of this, but I did some research, and it seems to be a common problem with virtual machines (the ones emulating hardware). The problem seems to be, that Java uses 1/4 ( MaxRAMFraction [1]) of the _physical_ memory as heap (Arguments::set_heap_size() [2]). If there is any limit, pushing java below this, it will fail (Consequently Andrew is likely to have 8GB of RAM locally).
If this is indeed the problem, the "physical" memory of those virtual machines must be reduced, or " -Xmx" must be set globally. Unfortunately I found no other solution then exporting e.g. _JAVA_OPTIONS="-Xmx64m".

[1] http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/b92c45f2bc75/src/share/vm/runtime/globals.hpp
[2] http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/40e7c1d24e4a/src/share/vm/runtime/arguments.cpp

[Andrew Ross (rockclimb)]

Morty, thanks for tracking down that information. You're right, I have 8GB of RAM on my local machine.

So if the problem is that the ulimit is lower than 1/4 of the total memory reported, then does adding more memory makes things worse, not better? In any case, I think you're right that having the launchpad build scripts set _JAVA_OPTIONS="-Xmx****" for **** to be determined would seem sensible. I'd vote for more than 64m as I'm reasonable sure we'll have packages that won't build in that, but something like 256m should be enough I suppose.

It's a shame that there are problems installing dependencies (e.g. setting up openjdk-6-jre-headless itself) otherwise this could be fixed just in the debian/rules file. In any case I'll add it to my debian/rules and see if that helps matters.

[Andrew Ross (rockclimb)]

Probably worth noting that debuild unsets _JAVA_OPTIONS so it needs resetting in debian/rules if it's needed from there.

[Jelmer Vernooij (jelmer)]

This is the current limit (from lp:launchpad-buildd, line 216 of buildrecipe):

    setrlimit(RLIMIT_AS, (1000000000, -1))

[Andrew Ross (rockclimb)]

OK, so we should expect failures on any build machine with more than 4GB of RAM then.

[Boris Rybalkin (ribalkin)]

This issue combined with the quota on build times per day may require several days of build attempts to get new version of a package into PPA. Is there any way to direct java recipe to the right build agents?

[Savvas Radevic (medigeek)]

Any updates on this one? I still have problems, but I don't want to retry 10 times to rebuild a package using a recipe.
Perhaps detect if there's java and redirect the building process to a specific build machine that can actually build it.

This way, I have to keep my fingers crossed every time I try to make a package :-)

https://launchpadlibrarian.net/181401129/buildlog.txt.gz
https://launchpadlibrarian.net/181401127/buildlog.txt.gz

ant clean
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

[Alberto Salvia Novella (es20490446e)]

@ Savvas Radevic

 - The procedure for making a bug as a papercuts is to set it as affecting the "One Hundred Papercuts" project, instead of subscribing the involved teams.

 - One Hundred Papercuts, in its work-flow, automatically filters bugs which aren't tagged with the names of the current and future Ubuntu release. So adding this report to the project will do nothing.

Nevertheless, thanks for reporting.

[Alberto Salvia Novella (es20490446e)]

I am asking now the "Canonical Launchpad Engineering" team to have a look at critical bugs in the "launchpad-buildd" project, as this one; since there have been some critical flaws for a long time.

[Colin Watson (cjwatson)]

Alberto: By way of explanation, many of these bugs were stalled for a long time due to circumstances outside our control: with the old Xen/hardy-based virtual builder infrastructure, we weren't able to fix many of these in any kind of sensible way. Now that the new OpenStack/trusty-based virtual builder infrastructure has been rolled out (which happened last Monday), we've finally been able to make progress again on some of these older buildd bugs.

[Savvas Radevic (medigeek)]

Thank you!!

On 6 August 2014 12:12, Colin Watson <email address hidden> wrote:

> Alberto: By way of explanation, many of these bugs were stalled for a
> long time due to circumstances outside our control: with the old Xen
> /hardy-based virtual builder infrastructure, we weren't able to fix many
> of these in any kind of sensible way. Now that the new OpenStack
> /trusty-based virtual builder infrastructure has been rolled out (which
> happened last Monday), we've finally been able to make progress again on
> some of these older buildd bugs.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/693524
>
> Title:
> Daily builds of Java packages fail: "Could not reserve enough space
> for object heap"
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/launchpad-buildd/+bug/693524/+subscriptions
>

[Colin Watson (cjwatson)]

Fixed in launchpad-buildd 126, now deployed on virtualised builders.