Open Bug 590713 Opened 14 years ago Updated 2 years ago

Javascript return value somehow affects speculative parsing test

Categories

(Core :: JavaScript Engine, defect)

x86
Linux
defect

Tracking

()

Tracking Status
blocking2.0 --- -

People

(Reporter: cmtalbert, Unassigned)

References

Details

This one is pretty far fetched and I wouldn't believe it if I wasn't trying to debug it.  So, on the Fedora Tinderbox Test slave (yes, and only there, does not repro locally on same version of fedora using same builds, tests, and instantiation method) if I change server.js (a core piece of mochitest test harness) then test_bug_534293.html cannot load a javascript file.  No other test seems to be affected, just this one.  And the changes don't seem to have any relationship at all:

I apply my patch to server.js to change the way we find tests in mochitest (enforcing the existing ^test.* rule, see the original patch on bug 584611).  But even if I make this seemingly innocuous change, the test will still fail.  Here's the change that makes it fail:
-  return filename.indexOf("test_") > -1 &&
+  // File name is a URL style path to a test file, make sure that we check for
+  // tests that start with test_.
+  var testPattern = /^test_/;
+  var pathPieces = filename.split('/');
+  var istest = testPattern.test(pathPieces[pathPieces.length - 1]);
+  return istest  &&
          filename.indexOf(".js") == -1 &&
          filename.indexOf(".css") == -1 &&
          !/\^headers\^$/.test(filename);

With this change in place, then test_bug534293.html[1] fails to load.  Specifically, the test fails to load the file_bug534293-slow.sjs [2] script.  And the test times out after waiting 30 seconds for something to happen.

Now, if I change the code in server.js to still perform the same operations but to use the old check for 'test' anywhere in the file name during the return statement, then test_bug_534293 passes.

+  // File name is a URL style path to a test file, make sure that we check for
+  // tests that start with test_.
+  var testPattern = /^test_/;
+  var pathPieces = filename.split('/');
+  var istest = testPattern.test(pathPieces[pathPieces.length - 1]);
+
  return filename.indexOf("test_") > -1 &&
         filename.indexOf(".js") == -1 &&
         filename.indexOf(".css") == -1 &&

All other tests with sjs scripts pass.  And I can't for the life of me figure out what could be affecting this behavior.

Is this a JS bug?  Is there some other way I can debug this more effectively?

[1] http://mxr.mozilla.org/mozilla-central/source/parser/htmlparser/tests/mochitest/test_bug534293.html?force=1
[2] http://mxr.mozilla.org/mozilla-central/source/parser/htmlparser/tests/mochitest/file_bug534293-slow.sjs
Blocks: 590874
Should I disable the test until this bug has been fixed? The test is causing quite a bit of orange and cross-test state leakage would explain why.
(In reply to comment #1)
> Should I disable the test until this bug has been fixed? The test is causing
> quite a bit of orange and cross-test state leakage would explain why.

Well, it sounds to me like this test is giving us more pain than help right now, so it sounds like a good idea to me. But that's just my opinion.
blocking2.0: --- → ?
blocking2.0: ? → betaN+
Seems like the sort of thing we should look into, but bang for the buck seems low right now.
blocking2.0: betaN+ → -
Assignee: general → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.