Cannot read property '33038646' of null - karma-junit-reporter/index.js:93:22 #61
Comments
|
hmm. I noted that in some browsers, each time karma launches the browser - a new tab is added to the browser, so I end up running the test on the browser X times - and that could be the source of a race-condition: It could be that one tab reported results and the test is closed, and then another tab opened to the karma server ends test and tries to report results. I can propose two alternatives: |
|
This is flaking on us as well. We get a different number of course. |
|
@osherx With the newest version 0.3.8 I get the following error: 29 12 2015 11:41:27.921:WARN [PhantomJS 1.9.8 (Windows 7 0.0.0)]: Disconnected (1 times), because no message in 10000 ms. |
|
I was getting this error regularly in a file watcher scenario. It would work the first time but fail often on subsequent runs. So I did some simple debugging and I found there are three functions at play. onRunStart, onBrowserStart, onRunComplete; they are intended to execute in that order. I found this error occurs when onRunComplete executes before onBrowserStart. |
|
Related: #20 |
|
@StanleyGoldman Can you elaborate on restartOnFileChange flag I cannot find it in karma-junit-reporte plugin doc. Do you have it in karma.config? Thanks! |
|
It's a karma setting that I put in my karma.conf. |
|
Thanks @StanleyGoldman |
|
I get this error too at random times on our Jenkins server - updating to use karma 0.13.21 seems to have helped (updated other karma relate npm modules to lates versione too). |
|
+1 |
|
Is #38 also related? |
|
This is flaking for us as well. |
|
Encountered this issue after this update: karma-junit version not changed and is 3.8.0 Bug reproduced on both linux (arch, ubuntu 14.04) and windows (10) with different bersions of node (4.2, 4.3) and npm (2.x, 3.x). All tests are correct and karma works correctly without junit. Karma launched using public js API: gulp.task('test-single', ['strict-check', 'prepare-test-config', 'bundle-templates'], function(done) {
var options = {
configFile: __dirname + '/../karma.conf.js',
singleRun: true,
autoWatch: false,
};
var runner = new Karma(options, done);
runner.start();
}); |
|
I fixed the |
|
I already reported it on the karma-runner-project, but maybe that was wrong: github-karma |
|
+1 |
|
seems to be related to usage of the karma-jasmine-html-reporter. If i exclude this reporter in karma everything is working |
|
Mm. I've gotten this and never used the jasmine reporter. |
|
Same here. i use the mocha reporter, the junit reporter, and sometimes the coverage reporter. |
|
+1 Here I use karma 1.3.0 and karma-junit-reporter 1.1.0 |
|
The same for me with "karma-htmlfile-reporter". I use "karma" 1.3.0 and "karma-htmlfile-reporter" 0.3.4 and "phantomjs" 2.1.7. |
|
+1 This one is pretty annoying. We also use karma-junit-reporter and karma-jasmine, but no jasmine reporter. |
|
Alright. A little poking around in index.js seems to confirm that this bug lives in the karma-junit-reporter. if( suites == null ) Basically initializing that thing if events fire in a different order. |
See karma-runner#61 (comment) as for why. What this mainly does is expose the real problem: onRunStart() firing out-of-order with the rest. Looks like there are some races somewhere, but I'm not convinced the problem lies within karma-junit-test itself. New error output: --- Running "karma:unit" (karma) task [D] Task source: C:\DATA\git\ymonitor-frontend\node_modules\grunt-karma\tasks\grunt-karma.js Verifying property karma.unit exists in config...OK File: [no files] Options: background=false, client={} 02 12 2016 16:17:47.082:INFO [karma]: Karma v0.13.22 server started at http://localhost:8084/ 02 12 2016 16:17:47.091:INFO [launcher]: Starting browser PhantomJS 02 12 2016 16:17:48.802:INFO [PhantomJS 2.1.1 (Windows 7 0.0.0)]: Connected on socket NHQQtIYrup2fNrbRAAAA with id 58745719 Warning: Task "karma:unit" failed. Use --force to continue. Error: Task "karma:unit" failed. at Task.<anonymous> (C:\DATA\git\ymonitor-frontend\node_modules\grunt\lib\util\task.js:205:15) at null._onTimeout (C:\DATA\git\ymonitor-frontend\node_modules\grunt\lib\util\task.js:241:33) at Timer.listOnTimeout (timers.js:92:15) Aborted due to warnings. ---
|
Any chance we can get a PR for this? |
|
I can reproduce this consistently as described in #99 (comment). Fix #110 is already merged into master, see if that works for you? |
|
I have that fix (#110). It doesn't help, unfortunately. Not sure why though. |
|
@randakar did you check out the code from master, rather than doing an npm install as the code with the fix hasn't been released yet. I will also look into it on Monday as it seems to be blocking all of our mac users from running their unit tests. Not sure if this helps anything, but we have about 100 devs on Windows 7 and eight Redhat CI boxes and none of them seem to have been affected by the latest occurrence of this bug. |
|
Yes. I checked out master when I built that patch and tested it. I will need to do some vesting to verify various potential solutions though. I wonder what is happening exactly and why. |
|
.. testing. Silly autocorrect. |
|
Alright. Quick testing seems to indicate that the commit in master actually changes the behaviour in question. Nonetheless, I'm still getting the error listed above, so I would not be surprised if something else breaks now due to things running concurrently. Also, I will send a new PR to implement robinj's suggestion to initialize suites earlier. It doesn't hurt, the whole way it's initialized now is slower and doing it early makes it pretty much immune to races. |
As karma-runner#61 (comment) Minor cleanup. Doing it this way should be faster though (no constructor call overhead, less code to begin with).
As #61 (comment) Minor cleanup. Doing it this way should be faster though (no constructor call overhead, less code to begin with).
As #61 (comment) Minor cleanup. Doing it this way should be faster though (no constructor call overhead, less code to begin with). * Release memory held by a testsuite after we're done with it. When a test finishes and the result has been written out the reference to the testsuite in the suites object can be dropped. Ideally we'd drop the reference from the array entirely but that involves recreating the array and *that* might race. So instead we just make the testsuite object point to 'null'.
|
@dignifiedquire I think this can be closed out now given the latest 1.2.0 release - shall we close this? |
|
This should be fixed, going to close this - comment here if it appears again with 1.2.0+ and we can reinvestigate. |
|
I'm still getting this error for |
|
As I've mentioned before: lots of modules have this problem. "var suites" got copied all over the place. I bet the coverage reporter has it's own incarnation of it. |
and others
reproduced here
https://github.com/el-net/bs_karma_eval
when run locally as:
reproduction is inconsistent :-(
full error:
The text was updated successfully, but these errors were encountered: