It looks like the shared memory size is tiny in comparison to the resource class. The Firefox browser (in a container) crashes when it has less than 2GB of shared memory – this is a pretty widely reported issue (see below) and is easily mitigated with a docker run flag (--shm-size=2g or -v /dev/shm:/dev/shm).
It seems like I can crash the Firefox browser in CircleCI by choosing a resource class smaller than xlarge. This is pretty ridiculous since the class has 16GB of memory – and there is less than 20% memory utilization.
To add a bit more information (and possible more reason to a bug in CircleCI infrastructure): we are now getting this in the extra large resource classes.
Does anyone know of any tips on memory debugging?
Or, how to escalate a bug report?
If you are using Selenium, I wonder if that is the parent process that starts Firefox. If so, maybe you need to set the JVM max memory settings in the java command used to start it up. It’s been ages since I used Selenium though.
If you get stuck and you can reliably reproduce the issue, drop a line to support@circleci.com to log a ticket.
