751101 - Disable js1_5/Regress/regress-328897.js for remote reftests

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Bobby Holley (:bholley)]

This has given us no end of pain. This used to be marked failing for remote reftests, then gabor somehow made it pass again in bug 735280, and now compartment-per-global makes it fail again.

In the absence of anyone willing to dig into this thing, I'd like to just mark it as skip for remote reftests and move on. Patch coming up.

Comment 1

[Bobby Holley (:bholley)]

Attachment: Disable js1_5/Regress/regress-328897.js for remote reftests. v1

Attaching a patch. Flagging bz for review.

Comment 2

[Gabor Krizsanits (INACTIVE)]

I think this failed originally because the original exception that was thrown from caps contained the uri, which in the remote case was different as expected in the test. In my patch the new exception is thrown from the wrapper do not contain that info, nor the regexp in the test, so there is no problem for the remote case. I have no problem with removing it from the remote reftests btw, just don't quite understand why is failing in the c-p-g version.

Comment 3

[Boris Zbarsky [:bzbarsky]]

What Gabor said.  This wasn't failing then not-failing because of random things.  The behavior was quite well-understood.  So why does CPG make it fail?

Comment 4

[Bobby Holley (:bholley)]

It just says:

REFTEST TEST-UNEXPECTED-FAIL | http://10.250.48.220:30216/jsreftest/tests/jsreftest.html?test=js1_5/Regress/regress-328897.js | load failed: null

FWIW I've only seen this once. I've done 4 try pushes since Gabor turned the test back on. Pushes 3 and 4 had this test disable. Test 1 crashed in JSReftest before we could get there.

Any ideas?

Comment 5

[Boris Zbarsky [:bzbarsky]]

That's an error message from the reftest harness itself.  It can only happen in IPC reftests.

If you got this message, that means that LoadFailed in reftest-content.js got called, and gFailureReason was null.  Which is what RecordResult sets gFailureReason to (e.g. for the previous test).

LoadFailed is called when the test times out.  See StartTestURI in reftest-content.js.

So it sounds like the test is timing out.  Which presumably means no onerror firing.  And if that's the case, then you're failing on the thing that the test is _meant_ to be testing.

Comment 6

[Ryan VanderMeulen [:RyanVM]]

Bobby, if this is indeed happening intermittently (I'd re-run the test in the same Try push 5ish times to see), it sounds likely to be yet another variant on bug 720452. Note that there are a lot of other "load failed: null" intermittent Android orange bugs filed and bug 720452 was basically morphed to cover all of them at this point.

Comment 7

[Bobby Holley (:bholley)]

Thanks Ryan! I've given this 3 try pushes, per your suggestion:

https://tbpl.mozilla.org/?tree=Try&rev=deaff2adf6c4
https://tbpl.mozilla.org/?tree=Try&rev=8bb332224947
https://tbpl.mozilla.org/?tree=Try&rev=11ea85d1cdeb

Comment 8

[Ryan VanderMeulen [:RyanVM]]

FYI, you can re-trigger tests using the self-serve API rather than creating multiple new jobs :)

Comment 9

[Bobby Holley (:bholley)]

Looks intermittent. Sweet!