TypeError: Cannot call method 'toString' of undefined in preprocessor.js

[sebarmeli]

Hey there,

I'm using the below conf (from spec/javascripts)

basePath = './../..';

files = [
  JASMINE,
  JASMINE_ADAPTER,
  'app/assets/javascripts/**/*.js',
  'spec/javascripts/**/*.js'
];

preprocessors = {
  './app/assets/javascripts/**/*.js': 'coverage'
};
reporters = ['progress', 'coverage'];
autoWatch = true;
coverageReporter = {
  type : 'html',
  dir : 'coverage/'
}
browsers = ['Chrome'];

singleRun = false;

and a few people in my team are getting this error:

ERROR [karma]: [TypeError: Cannot call method 'toString' of undefined]
TypeError: Cannot call method 'toString' of undefined
    at /Users/name.surname/workspace/cp-agentadmin/node_modules/karma/lib/preprocessor.js:42:26
    at fs.js:207:20
    at Object.oncomplete (fs.js:107:15)

Any clue?

Thanks,
Sebastiano

[vojtajina]

Can you debug this a bit ? Edit /Users/name.surname/workspace/cp-agentadmin/node_modules/karma/lib/preprocessor.js and print out the err - for some reason fs.readFile failed...

What text editor are you using ?

[sebarmeli]

This is the error I'm getting:

{ [Error: EMFILE, open '/Users/<name>/file.js']
  errno: 20,
  code: 'EMFILE',
  path: '/Users/<name>/file.js' }

I'm using ST2.

[kunday]

@vojtajina @sebarmeli I did more debugging on this and noticed that it's due to the file limit error. Looks like the ulimit for open file descriptors in Mountain Lion is 256 and once we hit that limit, node starts choking with EMFILE errors (ex: sample issue here - nodejs/node-v0.x-archive#2479 / nodejs/node-v0.x-archive#5401 ) I increased my file descriptor limit and the errors do go away. From the discussion in the google-groups I understand node core-team does not want to push a fix into their codebase in the interest of keeping things small.

• Arv

[vojtajina]

Yep, @kunday is right.

I say, increase the limit as a workaround for now, but we need solve this, without increasing the limit. We should make sure we don't hit the limit. It's however little bit more complicated (esp. because of file watching), so I'm creating a specific issue for it: #544

That said, how many files does your project have ? Because I'm on Mountain Lion with 256 as well and I never hit the limit, even with projects like Angular which has tons of files... Can you share your config ? I'm pretty sure you are watching or at least globing a lot of unnecesary files....

[sebarmeli]

I see and makes sense to solve this without manually increasing the limit.

This is my current config:

// base path, that will be used to resolve files and exclude
basePath = './../..';

// list of files / patterns to load in the browser
files = [
  JASMINE,
  JASMINE_ADAPTER,
  'vendor/assets/javascripts/**/*.js',
  {
    pattern: 'app/assets/javascripts/templates/**/*.html.haml',
    watched: true,
    included: false,
    served: true
  },
  'app/assets/javascripts/namespace.js',
  'app/assets/javascripts/models/**/*.js',
  'app/assets/javascripts/reference-data.js',
  'app/assets/javascripts/helpers/**/*.js',
  'app/assets/javascripts/routers/**/*.js',
  'app/assets/javascripts/collections/*.js',
  'app/assets/javascripts/application.js',
  'app/assets/javascripts/views/*.js',
  'app/assets/javascripts/views/*/**/*.js',
  'app/assets/javascripts/application.js',
  'spec/javascripts/support/jasmine-jquery-1.2.0.js',
  'spec/javascripts/support/jasmine-underscore.js',
  'spec/javascripts/support/sinon-1.1.1.js',
  'spec/javascripts/spec-helper.js',
  {
    pattern: 'spec/javascripts/fixtures/**/*.html',
    watched: true,
    included: false,
    served: true
  },
  {
    pattern: 'spec/javascripts/fixtures/**/*.json',
    watched: true,
    included: false,
    served: true
  },
  'spec/javascripts/helpers/**/*.js',
  'spec/javascripts/application/*.js',
  'spec/javascripts/collections/**/*.js',
  'spec/javascripts/models/**/*.js',
  'spec/javascripts/routers/*.js',
  'spec/javascripts/views/**/*.js',
  'spec/javascripts/integration/**/*.js'
];

exclude = [
  '**/*.swp'
];

preprocessors = {
  './app/assets/javascripts/**/*.js': 'coverage'
};

reporters = ['progress'];
port = 9876;
runnerPort = 9100;
colors = true;
logLevel = LOG_INFO;
autoWatch = true;
coverageReporter = {
  type : 'html',
  dir : 'coverage/'
};
junitReporter = {
    outputFile: 'test-reports.xml',
    suite: 'My Suite'
};
browsers = ['Chrome'];
captureTimeout = 60000;
singleRun = false;

(I know that dependencies are managed really bad so we need to have this confusing ordered list of JS files and specs)

We've got around 350 source files and 350 specs

[vojtajina]

Can you try running it without the coverage ? I think the preprocessor is the main problem issue.

[kunday]

@vojtajina Yep, that's correct. Coverage preprocessor is the main problem here.

[rbarreca]

Hey @vojtajina and @kunday, I'm getting this error now. When I run via commandline with a console.log(err); added I see:

ERROR [karma]: [TypeError: Cannot call method 'toString' of undefined]
TypeError: Cannot call method 'toString' of undefined
    at createPreprocessor (/usr/local/share/npm/lib/node_modules/karma/lib/preprocessor.js:53:33)
    at fs.js:117:20
    at Object.oncomplete (fs.js:297:15)
{ [Error: EMFILE, open '/Users/rob/Sites/<snip>/wrapper/WrapperUnitTests.js']
  errno: 20,
  code: 'EMFILE',
  path: '/Users/rob/Sites/<snip>/wrapper/WrapperUnitTests.js' }

I gisted my karma.conf.js. I'm new to node and karma, and was trying to workaround by putting fs.MAX_OPEN = 1024; on line 2 of preprocessor.js but I still get the error. Any ideas or more info I could give?

[rbarreca]

What's odd is that if I run this via IntelliJ, I don't get any errors.

[kunday]

rbarreca: Could it be possible that Intellij updates the ulimit when it runs?

[rbarreca]

@kunday yeah seems to make sense. Cool, ulimit was the Google term I was missing. ulimit -n 512 in the CLI fixed it there for me. Thanks!

[kunday]

@rbarreca I guess you might actually need ulimit -S -n 512 .

[iammerrick]

I'd be happy to contribute the fix to this if someone could point me in the right direction...

[rubenv]

Might be totally unrelated, but I'm seeing this error on Linux, where the file limit is set to 1024. Switching from graceful-fs back to fs fixes the problem there.