Running:
ava hola2.js -w
I changed the file 11 times. On the 11th time, I got this warning:
(node) warning: possible EventEmitter memory leak detected. 11 timeout listeners added. Use emitter.setMaxListeners() to increase limit.
Trace
at Api.addListener (events.js:252:17)
at /home/capaj/Documents/tests/node_modules/ava/api.js:252:9
at tryCatcher (/home/capaj/Documents/tests/node_modules/bluebird/js/release/util.js:16:23)
at Promise._settlePromiseFromHandler (/home/capaj/Documents/tests/node_modules/bluebird/js/release/promise.js:503:31)
at Promise._settlePromise (/home/capaj/Documents/tests/node_modules/bluebird/js/release/promise.js:560:18)
at Promise._settlePromise0 (/home/capaj/Documents/tests/node_modules/bluebird/js/release/promise.js:605:10)
at Promise._settlePromises (/home/capaj/Documents/tests/node_modules/bluebird/js/release/promise.js:684:18)
at Promise._fulfill (/home/capaj/Documents/tests/node_modules/bluebird/js/release/promise.js:629:18)
at MappingPromiseArray.PromiseArray._resolve (/home/capaj/Documents/tests/node_modules/bluebird/js/release/promise_array.js:125:19)
at MappingPromiseArray._promiseFulfilled (/home/capaj/Documents/tests/node_modules/bluebird/js/release/map.js:97:18)
at MappingPromiseArray.PromiseArray._iterate (/home/capaj/Documents/tests/node_modules/bluebird/js/release/promise_array.js:113:31)
at MappingPromiseArray.init (/home/capaj/Documents/tests/node_modules/bluebird/js/release/promise_array.js:77:10)
at Promise._settlePromise (/home/capaj/Documents/tests/node_modules/bluebird/js/release/promise.js:557:21)
at Promise._settlePromise0 (/home/capaj/Documents/tests/node_modules/bluebird/js/release/promise.js:605:10)
at Promise._settlePromises (/home/capaj/Documents/tests/node_modules/bluebird/js/release/promise.js:684:18)
at Promise._fulfill (/home/capaj/Documents/tests/node_modules/bluebird/js/release/promise.js:629:18)
Node.js v5.10.1
linux 4.2.0-35-generic
Thanks for reporting this!
This is actually already fixed in master due to the API refactor.
We were doing:
self.on('timeout', ...);
Where self was the API instance, and that was happening for every rerun.
We now attach to individual RunStatus instances.
I don't see a good way to write tests for this, but it's definitely fixed.
Closing.
I read this is fixed in master, but can you also publish that version to npm because 0.14.0 is not yet fixed?
I kept the code as simple as possible with latest npm module installed:
environment:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.3 LTS
Release: 14.04
Codename: trusty
$ node -v
v4.2.6
$ ava --version
0.14.0
index.es6:
"use strict";
module.exports = () => {
return Promise.resolve("bar")
}
test.js:
import test from 'ava'
const p = require('./index.es6')
test('foo', t => {
t.pass();
});
test('bar', async t => {
const bar = p()
t.is(await bar, 'bar');
});
I did have the error today as well on 0.14.0.
The API refactor was rather substantial. Substantial refactors introduce substantial regression risk. We keep them on master and dog food them on our own projects for a while before deploying. The warning is a nuisance, but can be safely ignored (you are unlikely to keep the watch daemon running long enough to be a problem).
You are welcome to install from master and help drive out bugs.
@jamestalmage I know the cause of this error. It is not a problem I worry about. This is only inconvenient for someone new to node.js who could think this error has to do with his own code.
It's definitely an AVA bug, just not one worth rushing to release a major refactor that hasn't been dogfooded yet.
Btw thanks for the library. I agree with @capaj tha people can think they are leaking memory while ava is doing this. I also understand @jamestalmage standpoint to first dog food, but I have two questions:
I understand that you guys are also probably busy. Maybe when I have some time available and I can I will sent a PR
Thanks,
Alfred Westerveld
Isn't it better to mention in README.md about this leak?
No point. We'll do a release soon. People encountering this can easily find this issue by searching.
Should this issue be closed, because when installing via npm it is not yet fixed?
Issues are closed when they're fixed, not released. This is true for most open source projects.
@sindresorhus thanks for quick reply. I guess you are right about those two points.
Most helpful comment
No point. We'll do a release soon. People encountering this can easily find this issue by searching.
Issues are closed when they're fixed, not released. This is true for most open source projects.