deasync
deasync copied to clipboard
abbr
Failed uv
Using deasync with redis and socket.io Under part of deasync
db.select = deasync(db.select);
db.set = deasync(db.set);
db.get = deasync(db.get);
db.del = deasync(db.del);
With many connections the fault message The failure message in uv
nodejs: ../deps/uv/src/unix/async.c:130: uv__async_io: Assertion `n == sizeof(val)' failed.is:issue is:open
I removed the deasync the db.set and db.get and stopped giving the problem. These methods set and get are called often.
Cannot reproduce with appended code on a c9 ubuntu instance running Node 4. Please post self-contained reproducible code and describe your env in order to reopen.
var deasync = require('deasync');
var redis = require("redis");
setInterval(function() {
try {
console.log(Date.now());
var client = redis.createClient();
client.on("error", function(err) {
console.log("Error " + err);
});
client.set = deasync(client.set);
client.get = deasync(client.get);
client.set("string key", Math.random());
redis.print(null, client.get("string key"));
client.quit();
}
catch (e) {
console.log(e);
}
}, 1);
Reproduced error Node version 4.1.1 Package versions is in package.json
Gist of the error: https://gist.github.com/ardemiranda/7baf355650eb30046929
I can reproduce the error - statistically about 1 out of 3-5 times. Also as you said, when avoid using deasync the problem is gone. But that doesn't necessarily mean the problem is caused by deasync because when I avoid using socket.io, the problem is also gone, see https://gist.github.com/abbr/7a456f0445255bdb5f56
i continue running into similar problems using superagent or ipc with unix-sockets. it looks like some of these libraries shut down something to early that the dasync-process is still needing. but after half a year of struggling to find the definite cause its still a bit vage. could be a relaesing-memory-timing-problem...
Hey,
In an Ubuntu server, i get this all the time from the following code:
var done=false;
child_process.exec(config.restaurantAPI.scriptName + " " + handleOrderObj.order._id,
function (error, stdout, stderr) {
console.log('stdout: ' + stdout);
console.log('stderr: ' + stderr);
if (error !== null) {
console.log("Error while sending order to the API: " + error);
errorCode = error.code;
}
done = true;
}
);
//making it sync.
deasync.loopWhile(function () {
return !done;
});
It happens 100% of the time! Therefore might be helpful for you. Let me know what kind of data would you like me to add.
Since the code i posted earlier was called from a mongoose.js callback (a save() of some model) the talked error was printed.
After taking the deasync code outside of that mongoose callback, the error stopped from printing to the log.
Hope it helps!
@tomerb15 - was having a similar issue, separate for mongoose, removing deasync from a callback resolved my problems. After quite a bit of testing it seems deasync doesn't always play well with socket.io.
@abbr - great module by the way - it has made some things I'm working on very easy.
Hey! I have the same problem on OSX. It is node v0.12.13, which is due to working in an meteor environment. It seems to run on my debian system though. The error occurs near a DDP call (I'm essentially waiting for the response of a DDP call), which internaliy uses socket.io I suppose.
Since libuv has updated, this assertion now comes from line 136 instead of line 130. I use deasync in my express application as well, but still not 100% sure deasync is the issue.
I reference this issue I opened on libuv: https://github.com/libuv/libuv/issues/1171
The assertion happens when uv__async_io hits EOF while reading fd "-1"... Does deasync mess with the eventfd that libuv is looking at?
Has anyone else confirmed that this bug has been caused by deasync. I have encountered a similar error message (uv__async_io: Assertion `n == sizeof(val)') using node 6.10 and node 8.11 and was wondering if someone could point us in the right direction for debugging this issue.
