unsetbit
Strange Test Failures
Trying to use Thrill as part of our builds, so that our unit tests run on all browsers.
We're seeing a strange issue that I'm not even sure how to debug:
Unable to get value of the property 'apply': object is null or undefined
http://internal_ip/p/457a902e-1366-4495-ba6f-b1446afaa6fd/g/94482878-a0d5-40af-84c5-3a124136eae4/tests/index.html:1
Any suggestions on where I can start looking to try and figure out where/why this issue occurs? Note that this only occurs on IE9. But if I run our tests on IE9 directly, there's no problem.
Possible confounding issues:
- Our test harness is QUnit
- The test page, index.html, uses the
<base>tag to go down one directory (../). We put in a fix for IE9 so it can deal with that relative base tag. - Using grunt-thrill task (specifying timeout, serve, host, and run options)
- Using RequireJS to load test files, so there's a significant delay between loading and calling QUnit.start()
Unfortunately, I doubt I can put up a reproduction case anytime soon, if at all. Just looking for suggestions on what to do to look for the problem, really.
Does the test work in other browsers and just not IE9? If not, my gut feeling is this is related to RequireJS and Thrill's autoadapt mechanism. Basically, Thrill tries automatically adapts to your testing framework (in your case, QUnit), by checking for a script tag with "qunit.js" in your ".html" files. If it can't find it, it won't be able to autoadapt, and if it doesn't autoadapt, there's no way for the test to talk back to the server. The solution to that would be to manually include https://raw.github.com/turn/thrill/stable/dist/thrill-qunit-adapter.js right after the QUnit file.
If it only fails on IE9, and you have an IE9 specific fix in place, it may be related to that. You can actually avoid using the base tag altogether by defining your files in the serve options:
// ... rest of config ...
serve: {
"index.html": "./someFolder/test/index.html"
"" : "./someFolder",
},
run: "index.html"
// ... rest of config ...
Looks like the thrill adapter stuff goes through fine - as it turns out, we've always found it easiest to simply leave the QUnit script tag in our testing files even when we're using RequireJS for everything else. Just makes life easier to do that and leave QUnit on window, in the end.
I'll try removing the base tag stuff later and seeing if that helps any.
Something potentially interesting to note - double checked the console in IE9 to check what errors it had on the console (as compared to what the thrill task was spitting out) - looks like Underscore is hitting an error on line 666, in the debounce method. No stack trace, unfortunately, so it really didn't seem to be much of a help either.
Ah, I didn't realize the error in your original message was from the Thrill task. In that case, yes Thrill is adapting and working fine with QUnit.
I think this is a pathing issue which is brought about with the base tag, IE9, Require and Queen. I would guess the debounce call is occurring because Require is trying to throttle it's requests. I would check the network tab in the dev console to see if you're getting and 404s, that may shed some light on which files IE9 is unable to find (if that is the issue).
Haven't had much time to experiment with this recently, just got back to it today.
One thing I can confirm: removing the base tag and the IE9 fix did not solve the issue. (Anecdotally, I seem to get fewer errors like the above, but still more than none). (For reference: the base tag fix we're using is an approximation of this answer on SO: http://stackoverflow.com/a/13373180. Technically, we insert a new base tag before the original one so it applies and not the old one, but it doesn't really matter much.)
But I did notice something interesting in the output this morning (happened to be after I remove the base tag stuff):
Died on test #2 undefined: Out of stack space
Unable to get value of the property 'apply': object is null or undefined
http://internal_ip/p/174c66eb-70d1-4e6b-8911-adb5afeb4620/g/2b93c06e-304d-46e6-83db-302dc39fc659/tests/index.html:1
As a second anecdotal note, we seem to run into various call stack issues with Thrill/Queen. For example, the guy running our queen server caught the failure one time and copied it:
[Queen] Connection on capture port didn't register within timeout period
_linklist.js:0
(function (exports, require, module, __filename, __dirname) { // Copyright Joy
^
RangeError: Maximum call stack size exceeded
This morning I also had to restart my IE9 Firefox, for example, which was only connected to the queen server, taking up 300,000K of memory in the IE9 task manager, and had that 'script running too long' popup going on. I have no idea if these are all related, but from an outsider's perspective, these all seem related, like event loop problems killing the stack space on both client & server or something.
Anyway...that's all I've got this morning. Does that give you any more ideas?
Which version of Node.js are you running? Versions before 0.8.18 had a problem with recursive calls in the network stack which I saw several times during development.
Another thing to check is adding stream: false to your config, this will significantly reduce network chatter by only sending tests results once the tests are complete (instead of streaming them as they happen).
Updated the version of node for our queen server; it's now at 0.8.21. Also added stream: false to our config.
Still see the same issue, give or take. All that gets reported to Thrill is a simple:
IE 9.0.0 (Windows 7) FAILED (TIMED OUT)
Stopped at test: undefined (undefined)
But on IE9, in the console before it gets cleared out, are various errors:
Unspecified error
jquery.js, line 9367 character 5
And:
Out of stack space
jquery.js, line 4027 character 2
So basically, the usual. Do you have an idea on the upper bound number of files that can be sent over with Thrill/Queen? Certainly, our tests import no small number of files, especially since we run our units tests by loading up individual RJS modules, not concatenated files.
Nope, no limits. I'll try to reproduce this sometime this week by creating a RequireJS setup (that seems to be the unique aspect of this that I haven't tested with). Could you post what your index.html looks like so I can try to mirror it?
Sure, that's possible. See this gist: https://gist.github.com/bmwyant/bddfdd8a978a97fd4708
Obviously the paths will be all screwy for you, but it happened to be easier not to mess with the paths much.
Note on library versions currently being used (we're certainly using other libs, but these should be the only ones that could matter in this context):
RequireJS: 2.1.2 QUnit: 1.11.0 jQuery: 1.8.2 (not technically seen in the gist, but see the comment in that we technically call QUnit.start() after waiting for DOMReady event) Underscore: 1.4.4 (really really irrelevant, perhaps, but can't hurt)