Develop Reference

Cypress Test Runner unexpectedly exited via a exit event with signal SIGSEGV in circleCI

I am stuck in this problem. I am running cypress tests. When I run locally, it runs smoothly. when I run in circleCI, it throws error after some execution.
Here is what i am getting:
[334:1020/170552.614728:ERROR:bus.cc(392)] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
[334:1020/170552.616006:ERROR:bus.cc(392)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[334:1020/170552.616185:ERROR:bus.cc(392)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[521:1020/170552.652819:ERROR:gpu_init.cc(441)] Passthrough is not supported, GL is swiftshader
Current behavior:
When I run my specs headless on the circleCI, Cypress closed unexpectedly with a socket error.
Error message:
The Test Runner unexpectedly exited via a exit event with signal
SIGSEGV
Please search Cypress documentation for possible solutions:
https://on.cypress.io
Platform: linux (Debian - 10.5)
Cypress Version: 8.6.0

Issue resolved by reverting back cypress version to 7.6.0.

I had this same issue on within our Azure builds as well. We only recently migrated from Cypress 8.4.0. Going back to that has solved the problem.

downgrade the cypress by running npm install cypress#7.6.0

Downgrade of cypress to 8.3.0 worked for me to solve that, you dont need to go to previous versions.
npm install cypress#8.3.0

SIGSEGV means a segmentation fault error. Read all about it here.
"In practice, a segfault occurs when your program breaks some
fundamental rule set by the operating system. In that case, the
operating system sends your process a signal (SIGSEGV on Mac & Linux,
STATUS_ACCESS_VIOLATION on Windows), and typically the process shuts
down immediately."
This blog post also goes into detail about how this can occur, even if you don't directly interact with the operating system (since we're writing JavaScript). Please read it on the original author's site for context.
But in short - you are likely encountering this error because
a. you upgraded Cypress while on an old version of NodeJS, or
b. you upgraded NodeJS, while you have Cypress code that is directly or indirectly incompatible (this could be your own code, or one of its dependencies) with that NodeJS version
Since SIGSEGV is a complete shutdown, you have no stack trace or debug information to guide you. So you have to debug the old fashioned way, turning tests and/or dependencies on or off to locate the problem in your code.

How to avoid using "kill <PID>" command every time on getting the error: listen EADDRINUSE nodeJS?

I'm running a simple MERN stack application on my local server(macOS). Although I figured out how to kill the process using the below statement, I wonder if there is a way to prevent getting EADDRINUSE error often?
kill -9 <PID>
I've been getting this error very regularly and it's affecting my productivity to kill and restart the server many times. Any insights on it?
Using nodemon v1.18.9 to monitor changes and start the server.

Heroku app crashing after a while from deployment. (node.js exress)

So my heroku app crashes with h10 codes and description is "app crashed". No more information. I will attach a screenshot about this (there is like 800 critical errors I can see in my heroku dashboard, and after deployment before a point it doesn't get any errors, then for some reason it starts having these critical errors then shuts down.)
Restarting the server fixes this but after a while it will crash again so I want to fix this properly.
https://imgur.com/22Uhcra Here is three of the errors with the "/" and favicon being more prominent.

An "app crashed" means the process running your app has crashed. This is probably an unhandled NodeJS exception crashing the process.
When this happens, Heroku will automatically restart the app, up to a certain point (apps restarting too often leads to capacity issues).
You should inspect your app's logs (a log retention add-on such as logentries will help there), and see where the first H10 is.
Right before that first H10, there will probably be a stacktrace showing where in your code the crash happens.

If you are using MYSQL make sure you have your connection set with createPool and not createConnection.
CreatePool dynamically creates db connections per your need, whereas createConnection will crash when overloaded.

Why would a NodeJS/restify server *rarely* report EPERM on accept?

I'm running a restify server in NodeJS. On very rare occasions, on the order of 0.05% of HTTPS requests cause net.js to report the following error:
Error: accept EPERM
at exports._errnoException (util.js:742:11)
at TCP.onconnection (net.js:1280:24)
There is nothing special about the HTTP requests. Before this error is reported, the server may have serviced thousands of requests and even responded to dozens of identical requests. I have not been able to find any information about why a server might generate an EPERM error for a socket that has been successfully accepting connections for several hours.
By the way, this error occurs outside of any execution context of our source code. So it's not as if the EPERM is about our code accessing a file or performing some other system call. The EPERM is happening deep within the NodeJS TCP code when the new request arrives and before our code is invoked.
At first, when the error occurred it would cause NodeJS to terminate. So then I added code to catch application-level exceptions:
process.on("uncaughtException", onUncaughtException );
But since I don't know why this error is happening, it's not at all clear what is the recovery process.
Not sure if it will matter, but here is most of the code relevant to starting up the restify service:
var restify = require("restify");
// skipping some other init code
// configuration data is read from a JSON file
var serverOptions = {
name: configuration.server.name,
version: configuration.server.version,
formatters: {
"application/json": jsonResponseFormatter,
"text/html": textResponseFormatter
},
serverOptions.key: fs.readFileSync(configuration.server.sslKey),
serverOptions.cert: fs.readFileSync(configuration.server.sslCert)
}
var server = restify.createServer( serverOptions );
// skipping middleware inits and URL registrations
server.listen(
configuration.server.port, // using HTTPS 443
configuration.server.serverip );
By the way, we are running an old version of NodeJS: v0.11.13. My long-term plan is to upgrade to the latest stable version, but we may not be able to update for a few months.

Let me leave my solution here in case anyone else stumbles across this same problem in the future.
Technically, I did not discover why this error was occurring, but I did find out how to handle the error condition successfully: trap and release. The error must be trapped at the application level because it is being generated deep within net.js outside any try-catch context of my source code. So if I don't trap it, then it will crash my application. But the error is non-fatal and it appears that it can be safely ignored. In testing, the socket continued to receive new connections even after this error occurred.
process.on("uncaughtException", onUncaughtException );
function onUncaughtException(error) {
// put some code here to log the error occurrence, then ...
if( error.code==="EPERM" && error.syscall==="accept" ) {
// non-fatal error: do nothing; just ignore this error
}
else {
// handle other application errors here
}
}
So while it might still be interesting to know why a server socket can occasionally have an EPERM error, for now I'm satisfied knowing the proper way to handle the error when it occurs.

$ man 2 accept
...
In addition, Linux accept() may fail if:
EPERM Firewall rules forbid connection.
To be honest, I'm not entirely sure what type of firewall rule would cause this error, all I can think of is that you may have a rule that allows incoming connections from a particular client but disallows outgoing data to that client's IP/network/port/...

Node.js - Server crashes when started on startup, doesn't crash when manually started

I am running Node.js and Socket.io for online chat.
I have created a file in:
/etc/init/example.conf
it has two lines:
start on startup
exec forever start /var/www/example.com/html/server.js //location of server file.
Whenever I start file upload in chat application, it crashes but instantly restarts.
Whenever I kill node process though, and start it manually - it works fine.
I also can't get any logs or anything from terminal as when it's auto started - it doesn't print me anything to terminal.
I am still new to Node.js and Linux in general.
Node.js is running on Express + Jade.
How do I determine specific cause?

I managed to solve my problem, after a bit of searching around I found out about tail command.
My issue was a bit harder to trace because Node.js was a process started by autostart so when I launched terminal and connected to server, process was just running in background basically and I wouldn't get any output (including exception messages).
Anyway, solution that worked for me was:
I typed
ps aux | grep node //to find PID of node process
then I went to following directory
cd /proc/[pid of running node service]/fd
In fd directory there are few objects you can get output from but if you want to attach and listen to servers output including uncaught exceptions, you need 1.
So:
tail -f 1
that way I was able to cause website to crash and see the output.