I do hundreds of request per second using the request module in nodejs and sometimes i get the following error
nodejs: ../deps/uv/src/unix/async.c:149: uv__async_io: Assertion `n == sizeof(val)' failed.
Code: null Signal: SIGABRT
how can i catch the signal?
An assert is blowing up, and that particular one is there to catch programming errors, or totally unexpected conditions. Another user reported this to us, but it turned out it was a missuse of the API. I suggest you open an issue on our bugtracker: https://github.com/libuv/libuv/issues, ideally with a reproducible reduced test case.
Related
Adding the console.log in this recursive function prevents NodeJS from throwing a "Maximum call stack size exceeded" exception. Instead it just exits after a couple thousand iterations with no message (using Node v16.6.0 on Win10).
Why does the console.log change the exception throwing behavior, and how should I catch this exception without removing the console.log?
(In browsers it also throws an exception as I expected.)
function recursive(i) {
console.log(i)
return recursive(i + 1) * 2
}
try {
recursive(0)
} catch (ex) {
console.log(ex)
}
There is no expected exception here.
Semantically, this is an infinite loop, which is valid. If the JS engine doesn't do tail call optimization infinite recursion (like your example) will cause the call stack to overflow, but this is neither required nor desired. The ECMAScript standard even states how tail calls should be optimized, though this isn't implemented in most JS engines (except for JavaScriptCore used in Safari/WebKit). Whether Node emits the Maximum call stack size exceeded exception or not is nothing you should rely on.
In NestJS the standard approach of handling errors is to let errors propagate up to the exception filter(s) so that code is not littered with try-catch blocks and exception logging and error conversion can be performed in one place.
With the move to node16, an event is thrown when there is no catch on a promise. This change seemingly leads to putting catch statements on all async calls. Is there a better approach that leverage the same exception filters methodology?
In node.js applications i saw usage of both these methods process.exit(1) and process.exit(0). Can anybody give me the exact answer ?
Node normally exits with a 0 status code when no more async operations
are pending. There are other exit codes which are described below:
1 - Uncaught Fatal Exception: There was an uncaught exception, and it was not handled by a domain or an uncaughtException event handler.
2 - Unused: Reserved by Bash for built in misuse.
3 - Internal JavaScript Parse Error: The JavaScript source code internal in Node's bootstrapping process caused a parse error. This is
extremely rare, and generally can only happen during the development
of Node itself.
4 - Internal JavaScript Evaluation Failure: The JavaScript source code internal in Node's bootstrapping process failed to return a
function value when evaluated. This is extremely rare, and generally
can only happen during the development of Node itself.
5 - Fatal Error: There was a fatal unrecoverable error in V8. Typically, a message will be printed to stderr with the prefix FATAL
ERROR.
6 - Non-function Internal Exception Handler: There was an uncaught exception, but the internal fatal exception handler function was
somehow set to a non-function, and could not be called.
7 - Internal Exception Handler Run-Time Failure: There was an uncaught exception, and the internal fatal exception handler function
itself threw an error while attempting to handle it.
8 - Unused
9 - Invalid Argument: Either an unknown option was specified, or an option requiring a value was provided without a value.
10 - Internal JavaScript Run-Time Failure: The JavaScript source code internal in Node's bootstrapping process threw an error when the
bootstrapping function was called. This is extremely rare, and
generally can only happen during the development of Node itself.
11 - Invalid Debug Argument: The --debug and/or --debug-brk options were set, but an invalid port number was chosen
>128 - Signal Exits: If Node receives a fatal signal such as SIGKILL or SIGHUP, then its exit code will be 128 plus the value
of the signal code. This is a standard Unix practice, since exit codes
are defined to be 7-bit integers, and signal exits set the high-order
bit, and then contain the value of the signal code.
Source: https://www.tutorialspoint.com/nodejs/nodejs_process.htm
You can find the answer to your question in the documentation: https://nodejs.org/api/process.html#process_process_exit_code
Basically if you want to exit with success use 0 if you want to exit with failure use 1.
0 is a success code and 1 (or another number) can be a failure code. 0 will be used if nothing is specified. Useful for passing information on the way out. Answered on SO here:
https://stackoverflow.com/a/5266239/5463636
More info direct from the Node.js docs here:
https://nodejs.org/api/process.html#process_process_exit_code
i have multiple threads running the following QProcess. Randomly they fail with error state 5. The Qt docs do not give any more details. Has anyone a clue what that error could come from? Thank you very much.
extCmd = new QProcess(this);
QString cmd = "/usr/bin/php";
QStringList argStr;
argStr << "/bin/sleep" << "10"; // changed to ever working command
extCmd->start(cmd, args);
bool suc = extCmd->waitForFinished(-1);
if (!suc) {
qDebug() << "finishing failed error="
<< extCmd.error()
<< extCmd.errorString();
}
Gives me the output:
finishing failed error= 5 "Unknown error"
Tangential to your problem is the fact that you should not be starting a thread per each process. A QProcess emits a finished(int code, QProcess::ExitStatus status) signal when it's done. It will also emit started() and error() upon successful and unsuccessful startup, respectively. Connect all those three signals to a slot in a QObject, then start the process, and deal with the results in the slots. You won't need any extra threads.
If you get a started() signal, then you can be sure that the process's file name was correct, and the process was started. Whatever exit code you get from finished(int) is then indicative of what the process did, perhaps in response to potentially invalid arguments you might have passed to it. If you get a error() signal, the process has failed to start because you gave a wrong filename to QProcess::start(), or you don't have correct permissions.
You should not be writing synchronous code where things happen asynchronously. Synchronous code is code that blocks for a particular thing to happen, like calling waitForCmdFinished. I wish that there was a Qt configuration flag that disables all those leftover synchronous blocking APIs, just like there's a flag to disable/enable Qt 3 support APIs. The mere availability of those blocking APIs promotes horrible hacks like the code above. Those APIs should be disabled by default IMHO. Just as there should be a test for moving QThread and derived classes to another thread. It's also a sign of bad design in every example of publicly available code I could find, and I did a rather thorough search to convince myself I wasn't crazy or something.
The only reasonable use I recall for a waitxxx method in Qt is the wait for a QThread to finish. Even then, this should be only called from within the ~QThread, so as to prevent the QThread from being destroyed with the tread still running.
I was wondering if Node.js provides any guarantee that the error handler will catch all errors in code like the following:
var c = net.createConnection(port, host);
c.on('error', function (e) { ... });
I've had to deal with code where other statements intervened between the call to createConnection and the statement which sets the error handler, and this sometimes caused errors internal to createConnection to percolate to the top level (presumably because these errors sometimes occurred before the error handler had been set). But unless I'm missing something, this could in principle happen in the code above -- it's just not very likely. Is there any way of actually guaranteeing that all errors which occur within createConnection will get passed to the error handler?
It will only happen if there are bugs in node.
JavaScript is single threaded, the process will not normally be interrupted between attaching the event handler and creating the connection.
No error generated in javascript land will be uncaught by that code.
So if there was a bug in node, there could probably be some errors your code would not catch. If you had some dodgy low level code running in the background causing mayhem it could be possible that some errors would occur that your code would not catch.
But under normal usage, your code is "threadsafe". Your binding the event handler before any errors occur because your code is blocking and nothing can throw errors.