1395366 - Intermittent js/src/jit-test/tests/modules/missing-export-offthread.js | Timeout (code -9, args "--baseline-eager") [150.0 s]

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P5)

Description

[Treeherder Bug Filer]

Filed by: wkocher [at] mozilla.com

https://treeherder.mozilla.org/logviewer.html#?job_id=126850002&repo=autoland

https://queue.taskcluster.net/v1/task/D9zQYPAXSISz5Gvs0AYz6A/runs/0/artifacts/public/logs/live_backing.log

Comment 1

[Intermittent Failures Robot]

26 failures in 113 pushes (0.23 failures/push) were associated with this bug yesterday.   

Repository breakdown:
* autoland: 13
* mozilla-central: 11
* mozilla-inbound: 2

Platform breakdown:
* linux64: 26

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1395366&startday=2017-08-30&endday=2017-08-30&tree=all

Comment 2

[Joel Maher ( :jmaher ) (UTC -8)]

there are 30 failures documented for this failure in the last 2 days:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1395366

these are linux64/debug spidermonkey-sm-compacting/debug jobs.  In fact we rarely run this and it is about 90% failing (effectively perma fail)

:naveed, I see you are the triage owner for this component, is this something you can find the right person to look at this?

Comment 3

[Luke Wagner [:luke]]

I was curious if one of our HelperThreads patches caused this so I bisected, but it looks like, quite surprisingly:

The first bad revision is:
changeset:   377646:fce9e9b0be2b
user:        Masatoshi Kimura <[e-mail]>
date:        Fri Aug 25 22:29:07 2017 +0900
summary:     Bug 1098412 - Remove the legacy Iterator constructor. r=luke

I'll see if I can't see what it is real quick.

Comment 4

[Luke Wagner [:luke]]

I think bug 1098412 is not at fault, it just tickled GC order in a way that exposes a latent bug:

The test calls StartOffThreadParseModule() however, because a GC is in process, the ModuleParseTask is enqueued in the  parseWaitingOnGC list.  When the current GC finishes, EnqueuePendingParseTasksAfterGC() is called, which goes through all the tasks in parseWaitingOnGC, but task->parseGlobal->zone()->wasGCStarted() is true so the ModuleParseTask stays in the parseWaitingOnGC list and never gets dispatched.  Finally, when FinishOffThreadModule() is called, OffThreadParsingMuustWaitForGC() returns false (despite the GC still being started), so there is no gc::FinishGC(cx) call and so it waits forever.

Seems like OffThreadParsingMustWaitForGC() (which just returns rt->activeGCInAtomsZone()) is too narrow.  Unconditionally calling gc::Finish(cx) in FinishOffThreadModule() fixes the hang but probably isn't the right fix.  Jon, do you know what is?

Comment 5

[Intermittent Failures Robot]

21 failures in 233 pushes (0.09 failures/push) were associated with this bug yesterday.   

Repository breakdown:
* try: 10
* mozilla-inbound: 7
* autoland: 4

Platform breakdown:
* linux64: 21

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1395366&startday=2017-08-31&endday=2017-08-31&tree=all

Comment 6

[Intermittent Failures Robot]

77 failures in 939 pushes (0.082 failures/push) were associated with this bug in the last 7 days. 

This is the #27 most frequent failure this week. 

** This failure happened more than 75 times this week! Resolving this bug is a very high priority. **

** Try to resolve this bug as soon as possible. If unresolved for 1 week, the affected test(s) may be disabled. **  

Repository breakdown:
* autoland: 25
* mozilla-inbound: 22
* mozilla-central: 18
* try: 12

Platform breakdown:
* linux64: 77

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1395366&startday=2017-08-28&endday=2017-09-03&tree=all

Comment 7

[Jon Coppeard (:jonco)]

Attachment: bug1395366-helper-thread-group

First of all this reverts the change I made in bug 1322648 to not enqueue parse tasks if their zone is being collected which is what's causing problems here.

The main change is to prevent zones indented for use by helper threads from being collected before that use has started.  This is accomplished by adding more state in the zone group.  There's some fiddling necessary to ensure that the state is reset correctly on error so that we can always clean up these zones correctly.

Comment 8

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

Comment on attachment 8904207 [details] [diff] [review]
bug1395366-helper-thread-group

Review of attachment 8904207 [details] [diff] [review]:
-----------------------------------------------------------------

Much nicer. What do you think of changing createdForHelperThread to ownedByHelperThread? It's a little weird that createdForHelperThread can change over a lifetime. And I *think* it would be parallel to ownedByCurrentThread, more or less?

Hm. Except it's *not* the same, because ownedByHelperThread would be set to true before it is done being used by the main thread, which seems wrong. reservedForHelperThread would be weird after it becomes Active.

You know, never mind. createdForHelperThread is fine.

::: js/src/gc/ZoneGroup.h
@@ +72,5 @@
> +  public:
> +    // Whether a zone in this group was created for use by a helper thread.
> +    bool createdForHelperThread() const {
> +        return helperThreadUse == HelperThreadUse::Pending ||
> +               helperThreadUse == HelperThreadUse::Active;

Arguable, but it feels like it would be very slightly simpler to understand if this were helperThreadUse != HelperThreadUse::None.

Comment 9

[Intermittent Failures Robot]

20 failures in 155 pushes (0.129 failures/push) were associated with this bug yesterday.   

Repository breakdown:
* mozilla-inbound: 8
* autoland: 8
* mozilla-central: 3
* try: 1

Platform breakdown:
* linux64: 20

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1395366&startday=2017-09-05&endday=2017-09-05&tree=all

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/f80146e7ec85
Extend zone group's state to cover those intended for future use by helper threads and disallow GC of such groups r=sfink

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/22a0a710fbf9
Fix bustage caused by missing explicit keyword r=me

Comment 12

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/f80146e7ec85
https://hg.mozilla.org/mozilla-central/rev/22a0a710fbf9

Comment 13

[Intermittent Failures Robot]

47 failures in 924 pushes (0.051 failures/push) were associated with this bug in the last 7 days.   

** This failure happened more than 30 times this week! Resolving this bug is a high priority. **

** Try to resolve this bug as soon as possible. If unresolved for 2 weeks, the affected test(s) may be disabled. ** 

Repository breakdown:
* autoland: 21
* mozilla-inbound: 16
* mozilla-central: 7
* try: 3

Platform breakdown:
* linux64: 47

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1395366&startday=2017-09-04&endday=2017-09-10&tree=all

Comment 14

[Intermittent Failures Robot]

2 failures in 718 pushes (0.003 failures/push) were associated with this bug in the last 7 days.    

Repository breakdown:
* try: 2

Platform breakdown:
* linux64: 2

For more details, see:
https://treeherder.mozilla.org/intermittent-failures.html#/bugdetails?bug=1395366&startday=2018-06-25&endday=2018-07-01&tree=trunk