309979 - lhasa runs out of memory linking libgklayout.so (no linux gtk2 nightlies)

Status: RESOLVED FIXED

(SeaMonkey :: General, defect)

Description

[Andrew Schultz]

when lhasa in (SeaMonkey-Ports) attempts to link libgklayout.so, it fails with:

/usr/bin/ld: final link failed: Memory exhausted

Comment 1

[Andrew Schultz]

lhasa spit out a build early this morning.

Thanks to whoever fixed it up.

Comment 2

[Jason Bassford]

No specific bug / patch referenced as the fix.

-> WORKSFORME

Comment 3

[Andrew Schultz]

reopening... this apparently got a bandaid or magically started working before and now it's back

Comment 4

[Andrew Schultz]

it must be magic

Comment 5

[Andrew Schultz]

magic fairy dust needed again
/me wonders if rebooting is magic

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Restarting the X server might be sufficient.

Comment 7

[Andrew Schultz]

seems to work again

Comment 8

[Andrew Schultz]

and again

Comment 9

[J. Paul Reed [:preed]]

Lhasa is slated to get moved to a VM; let's just keep this bug open for now, so we remember to give the VM more memory than the physical lhasa has now (which is a whopping 128 megs).

Comment 10

[Chris Cooper [:coop] (he/him)]

*** Bug 339502 has been marked as a duplicate of this bug. ***

Comment 11

[Chris Cooper [:coop] (he/him)]

I've disabled the SeaMonkey-Release builds on lhasa until the VM migration is complete. This should shorten the cycle for the other builds on the box.

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The X server is currently at 130 megs of memory usage.  That's probably the problem, and restarting it would help.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Chris, if lhasa is not going to be building the gtk2 seamonkey builds, could we switch comet to doing it?  The gtk1 builds it produces are largely useless anyway (printing doesn't work).

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

A complete OS reinstall would probably be the quickest way to make comet meet those build requirements, at which point we're better off using a new machine.

Comment 15

[Frank Wein [:mcsmurf]]

*** Bug 340023 has been marked as a duplicate of this bug. ***

Comment 16

[Robert Kaiser]

lhasa was the primary Linux nightly release machine for SeaMonkey trunk (it was doing GTK2 builds, which are the default ones now), so this means we've been lacking tier-1 Linux nightlies for some time now...

Could we just set up a new VM box meeting the new build prerequisites and configure it to do GTK2 SeaMonkey nightlies? lhasa's configuration is obsolete anyways, and it's previous perf data is not important, just the build do count and those as as good (or actually even better as it could build cairo) from a newly set up VM box as from a migrated one.

Where we have well-working machines with good configurations, it's reasonable to migrate those to VMs before thinking orf new ones, but in this case I'd vote for ditching the old machine and configuration completely and start over with a current and clean VM machine and configuration.

Comment 17

[Mike Schroepfer]

Can you detail out the needed specs for the machine (OS Version, libraries, etc) and we'll see if the build team can stand up a new VM to replace lhasa.  From previous attempts at this we'll keep lhasa around until we are sure the new VM is building properly.

Comment 18

[Andrew Schultz]

The simplest solution would be to clone argo-vm that's making firefox nightlies.  There's really no difference in build reqs for SeaMonkey and Firefox.

The box I'm using now to make builds is a stock Fedora Core 3 install (with updates).  I can give you a listing of the relevant packages if you want.  Red Hat Enterprise Linux 4 should work just as well (it's basically an enterprise version of FC3).

pango 1.6 (for cairo) is the main requirement that necessitates an FC3 or later install.  Any distro version that includes pango 1.6 is very likely to satisfy all other requirements.

Comment 19

[J. Paul Reed [:preed]]

lhasa is now running in a VM, but it's building a SeaMonkey 1.7-branch release build and a "Testerbox" build; I don't think this is entirely right.

There's a "SeaMonkey-release" build commented out, so maybe that's it?

Anyway, the VM has way more memory, so if we can get it building the right thing, we should be able to get SeaMonkey nightlies again.

Comment 20

[Andrew Schultz]

preed: see comment 11.  The problem predates that.

Comment 21

[Chris Cooper [:coop] (he/him)]

I disabled the SeaMonkey trunk build because of the memory issue that prevented it from ever completing. It should be safe to re-enable it now.

Comment 22

[Boris Zbarsky [:bzbarsky]]

Ok, so could we do that, please?

Comment 23

[Robert Helmer [:rhelmer]]

Seamonkey-Release is re-enabled, and tinderbox restarted on the new lhasa VM.

Comment 24

[Matt Seitz]

Would someone add "gtk2 build fails" to the summary, so users searching Bugzilla can find why there is no gtk2 nightly build?

Comment 25

[Robert Helmer [:rhelmer]]

Seamonkey-Release is still failing during tests; seems to be looking for the wrong profile directory:

( from http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1149882900.28088.gz&fulltext=1 ):

ERROR: profile /builds/tinderbox/SeaMonkey-Release/Linux_2.4.20-28.8_Depend/.mozilla/seamonkey/ does not exist

I am rebuilding now so I can run tinderbox in --test-only mode to debug, if anyone knows why this is happening let me know.

Comment 26

[Robert Kaiser]

Umm... what $VendorName is specified in tinder-config for that build?
$VendorName should be empty and $ProductName should be 'SeaMonkey' (or 'Mozilla'), ideally, for a normal SeaMonkey build.

Comment 27

[Andrew Schultz]

OK, the new lhasa just made a build (thanks, all!).  Can this be closed for good now?