Open Bug 929498 Opened 6 years ago Updated 6 years ago

fix test_asmjs.html mochitest to not run so long on slow machines

Categories

(Core :: JavaScript Engine, defect)

defect
Not set

Tracking

()

ASSIGNED

People

(Reporter: luke, Assigned: luke)

Details

(Whiteboard: [leave open][test disabled on Android])

Attachments

(1 file)

This test does some big long loop to test the operation callback.  Of course, this will run longer on slower machines, and much longer on much slower machines.  According to philor this test is probably causing panda boards to time out occasionally.  A simple fix is to control the duration of the loop with Date.now().
Attached patch fix-testSplinter Review
This changes the tests to execute for 3 seconds from the main thread and 3 seconds from the worker, regardless of CPU speed.
Attachment #820597 - Flags: review?(sstangl)
Whatever it was that suddenly made this so failure prone isn't getting any better, and it's failing abysmally often, like I might speculatively land this pending-review before Monday's merge to aurora, just in case it would keep me from having to see Android mochitest-7 fail two or three times per push for the next 18 weeks.
Alas, https://tbpl.mozilla.org/php/getParsedLog.php?id=29667175&tree=Mozilla-Inbound, that apparently wasn't whatever its silent problem is.
Whiteboard: [leave open]
Ahh, when I look at the logs again, I see it's not a timeout: in the logcat, we're actually dying from a SIGSEGV.  The faulting address == pc which means that this is the intentional SIGSEGV caused by the operation callback and it's just not getting handled correctly.  Mike was saying that some Android versions don't call handlers and EnsureAsmJSSignalHandlersInstalled() tests IsSignalHandlingBroken() for this reason.  Mike: are the pandas known broken?

Anyhow, my change probably made this perma-orange.  We know that the thing that's actually being tested here works on real Android devices so, while we figure out why this doesn't work on the pandas, can you disable this test for android?
I put some spew in the signal handlers in a try push:
https://tbpl.mozilla.org/?tree=Try&rev=5890fc1bcacd

In the two tests that fail, there is a:
  I/GeckoConsole( 2242): Triggering operation callback
followed by a crash.  The asm.js handler is never called.

In the four tests that pass, there is a nice sequence of:
  I/GeckoConsole( 2230): Triggering operation callback
  I/GeckoConsole( 2230): asm.js handler called
1 a second for the 3 seconds the test runs.

I just tested on a Nexus 4 several times in a row, and every time, the asm.js handler is called, so I'm guessing this issue is somehow very particular to whatever configuration is running on these Panda boards.

Have you seen any troubles Mike?
I had a hard time deciding between the undocumented android.json and the undocumented mochitest.ini methods, but wound up choosing the latter. https://hg.mozilla.org/integration/mozilla-inbound/rev/7163aa55ea70
Whiteboard: [leave open] → [leave open][test disabled on Android]
Though had I realized this was going to go from virtually never on aurora to nearly always on beta, I would have gone with the method that would work on 26 too. https://hg.mozilla.org/releases/mozilla-beta/rev/93544fa24586
Attachment #820597 - Flags: review?(sstangl) → review+
You need to log in before you can comment on or make changes to this bug.