Created attachment 3016 [details] log file Found while testing 2.0.1 RC7: b1f23d1254682866236bfaeb843c0d8aa332efc2 nightly-world failed on our local AB machines while building webkitgtk with a compiler error as follows: | {standard input}: Assembler messages: | {standard input}:12722: Warning: end of file not at end of a line; newline inserted | {standard input}:13966: Error: bad register name `%' | {standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive | i586-pokymllib32-linux-g++: internal compiler error: Killed (program cc1plus) See attached full log.
Alex holds the record for number-of-webkit-rebuilds, so Alex: have you seen anything like this before? If not I suspect we'll keep it open for a bit and close if nobody can replicate on demand or at least more than once.
Nope, never seen before. I haven't built the very latest master yet though, have been fighting introspection issues this entire week.
Also present in 2.1 M3 RC1: 8debfea81e69d038bd2d56314b272cb74f5582ed
Still present as of M3.rc2: 21823cb466e79540567ad1a43ae6f93d850e4057
> nightly-world failed on our local AB machines while building webkitgtk with a > compiler error as follows: Is this a 32 bit host?
Sorry, sent that a bit fast. I'm asking because I'm betting the compiler runs out of memory for some reason. A 32-bit host would be one possible, another is being too cheap on the VM settings: can you check how much memory the host has and (if it's a VM) maybe try doubling that?
And one more thing to confirm my suspicion: can you check system logs from the time of compile? It should have messages about running out of memory and killing a compiler process.
(In reply to comment #6) > Sorry, sent that a bit fast. > > I'm asking because I'm betting the compiler runs out of memory for some > reason. A 32-bit host would be one possible, another is being too cheap on > the VM settings: can you check how much memory the host has and (if it's a > VM) maybe try doubling that? It's 64-bit. All 4 are. As for memory....All the machines have 8GB of RAM assigned plus another 8GB swap. I'll try to increase that, but I'm not sure how much I have available to add. Just to test this hypothesis, I can double one machine's RAM, but I don't know if I can increase it permanently for all 4 of our VMs. Will update once I test these settings.
(In reply to comment #8) > It's 64-bit. All 4 are. > As for memory....All the machines have 8GB of RAM assigned plus another 8GB > swap. > I'll try to increase that, but I'm not sure how much I have available to > add. Just to test this hypothesis, I can double one machine's RAM, but I > don't know if I can increase it permanently for all 4 of our VMs. I just realised: you are compiling a lib32-webkit. I have a strong suspicion this is the problem: I believe it's compiled using a32bit compiler that can only access 4 GB of memory. If this is the case then fiddling with the VM settings won't help: don't waste your time. Maybe there's something we can do about this, but I have to ask: is 32bit webkit something you really need?
Adding more RAM seems to have fixed this problem. webkitgtk is now building successfully which has lead to finding a new bug with a package that had webkitgtk as a prerequisite bug 9174 For reference, the machines now have 15GB RAM, 8GB swap. Before they had 8GB RAM and 8GB swap.
(In reply to comment #10) > Adding more RAM seems to have fixed this problem. webkitgtk is now building > successfully which has lead to finding a new bug with a package that had > webkitgtk as a prerequisite bug 9174 > > For reference, the machines now have 15GB RAM, 8GB swap. Before they had 8GB > RAM and 8GB swap. Sorry, wrong bug number above, i meant bug 9374
It's resolved then? Thanks for the ( > I just realised: you are compiling a lib32-webkit. I have a strong suspicion > this is the problem: I believe it's compiled using a32bit compiler that can > only access 4 GB of memory. If this is the case then fiddling with the VM > settings won't help: don't waste your time. A '32 bit compiler' is an ambiguous term : in this case the compiler is producing 32 bit target binaries, but it is still a full 64 bit binary itself, if the host is 64 bit, and so there is no 4 GB limit. Anyway... RESOLVED/NOTABUG I guess? Thanks for the diagnostics and testing.
(In reply to comment #12) > Anyway... RESOLVED/NOTABUG I guess? Thanks for the diagnostics and testing. Marking as verified.