1093355 - Flaky hazard analysis runs

Status: RESOLVED FIXED

(Core :: JavaScript: GC, defect)

Description

[Steve Fink [:sfink] [:s:]]

Bug 1062888 - https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=307c6fa1d3c6 shows persistent hazard analysis failures. But they are different, and that push makes a good representative for the haz flakiness we've been seeing recently.

The problems in the first two haz builds in that push are:

08:49:46     INFO -  uncaught exception: assertion failed: GC function not found: void js::gc::GCRuntime::collect(uint8, int64, uint32, uint32)

11:03:37     INFO -  /builds/slave/sixgill/util/hashtable_impl.h: 111: LookupSingle: Assertion 'list != NULL' failed.

So the first managed to finish successfully but the resulting DB mysteriously did not contain an expected function. The second seems like it had a corrupted internal sixgill hashtable. Wtf?

I note that both of these took well over an hour. Successful builds generally take 23 minutes. I smell memory problems again.

Comment 1

[Nicolas B. Pierron [:nbp] {away}]

Same issues with Bug 1050160 - https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=276053e8f9d4

Is there a way I can help fixing these issues?

Comment 2

[Steve Fink [:sfink] [:s:]]

Attachment: Artificially limit the browser build to -j4 to control memory usage

This is basically bug 1045165 for the browser build.

Comment 3

[Pete Moore [:pmoore][:pete]]

Attachment: bug1093355_mozharness_v2.patch

Bustage fix

Comment 4

[Pete Moore [:pmoore][:pete]]

Checked in code deployed to production

Comment 5

[Pete Moore [:pmoore][:pete]]

Hi Steve,

Are we good to close this bug now?

Thanks,
Pete

Comment 6

[Steve Fink [:sfink] [:s:]]

I think so. I'll open a new bug if needed, anyway. Thanks!