I have a meteor/react/redux app that giving me out of memory errors during compile (meteor build) on our CI server on meteor 1.5.2, which is odd because it is actually a significantly smaller code base than other apps that don’t get out of memory errors. Regardless, it was working fine locally.
Given 1.6’s node upgrade, and reduced dependency on babel plugins, I was hopeful that 1.6 would reduce the memory footprint and speed up builds. I just upgraded it to 1.6. The upgrade appeared to complete fine.
With 1.6, when I try to run locally I get the following output:
> meteor
#
# Fatal error in ../deps/v8/src/api.cc, line 1248
# Check failed: !value_obj->IsJSReceiver() || value_obj->IsTemplateInfo().
#
=> Exited from signal: SIGILL
=> Your application is crashing. Waiting for file change.
I tried upgrading node on my development machine to 8.9.0 with the same result.
I’m going to have to revert to the last checkin (meteor v1.5.2). Any ideas what would cause this? There wasn’t any official 1.6 upgrade docs that I could find when I attempted this so it’s possible that user error is a factor.
Well, I figured out why the builds were running out of memory, at least. I had accidentally removed TOOL_NODE_FLAGS: '--max-old-space-size=4096' from the ci spec, which allows meteor to use the total available memory on our CI servers. Ops.
After some google searching on the specific node error, I see people are having similar issues (but not exactly the same) with node if they don’t rebuild their native modules or haven’t updated their package deps in some time. For example, one person had a year-old dep that caused the issue.
Unless I hear otherwise, I guess my plan is to just stay on 1.5.2.2 and wait until package maintainers upgrade their dependencies and hope that fixes the problem.
Same issue here with an older app–any idea how to view the whole stack trace? There should be a way to see exactly where node is slipping up, and correct the package that is out of date.
@dancastellon Unfortunately, no. It’s not critical for us to move to 1.6 right now and it wasn’t worth the time investment. Sometime in the next 3 months, I’ll probably take it up again.
Sorry. I’m sure it’s not the answer you were looking for.
@dpankros Trial and error led me to a few older meteor packages I had created that were targeting Meteor 1.0/1.1. I’ve since moved those Meteor packages to modules and everything is working great.
@jfols Do you know what about those packages caused it to fail? Were you able to narrow it down? It might help us to narrow our search for offending packages.
It’s been so long that I can’t honestly remember what’s changed in packages since the 1.0/1.1 days, other than npm support.
A SIGILL should be producing a core dump, assuming the machine is configured to save core dump, which can be usually be done by running:
ulimit -c unlimited
…before the command which is expected to dump its core. If you can get the core dump, I recommend analyzing it with a tool like autopsy. It can get a bit hairy, but it’s usually insightful. The autopsy docs are pretty good but this is a reasonable article on some of the techniques involved in that process: https://www.reaktor.com/blog/debugging-node-js-applications-using-core-dumps/.
It would be great if you could share the trace you retrieve from such a process!
I’m not sure exactly what is about those packages that’s causing the issue, honestly I was just hacking big chunks of the code base off as a last resort. Once I found the packages caused the issue I moved them into modules and moved on since I (hopefully) won’t ever hit this issue again.
