TypeError: Cannot read property 'toString' of null

[brent-hoover]

Not 100% sure on the origin of this error but it does seem to be happening on the release-0.18.0 branch and not on master. Putting in this ticket as a place to gather data.

The only steps to reproduce are start the app and wait. Sometimes it happens right away and sometimes it doesn't but it definitely has nothing to do with doing anything in the app as I have got the error before even opening a browser.

Full stack trace:

/private/var/folders/jl/zpw4rhsn4fj9gj3vx_vd47nh0000gn/T/shelljs_bdb847daf4fdd980a781:4
  fs.writeFileSync("/var/folders/jl/zpw4rhsn4fj9gj3vx_vd47nh0000gn/T/shelljs_46dfd0297ddd12e3e079", err ? err.code.toString() : '0');
                                                                                                                  ^

TypeError: Cannot read property 'toString' of null
    at /private/var/folders/jl/zpw4rhsn4fj9gj3vx_vd47nh0000gn/T/shelljs_bdb847daf4fdd980a781:4:115
    at ChildProcess.exithandler (child_process.js:214:5)
    at emitTwo (events.js:106:13)
    at ChildProcess.emit (events.js:191:7)
    at maybeClose (internal/child_process.js:852:16)
    at Socket.<anonymous> (internal/child_process.js:323:11)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:188:7)
    at Pipe._handle.close [as _onclose] (net.js:492:12)
exec: internal error

[aaronjudd]

I can confirm that this seems be the reaction-cli masking an error where meteor is just exiting with an abort code (Abort trap: 6 or abort meteor), with no error output. we see this when running meteor instead of reaction. This seems to be the same issue reported in meteor/meteor#8002. However, increasing file descriptors does not appear to resolve the issue.

[brent-hoover]

The error does not seem to occur if you switch to Meteor 1.4.1 using the --release switch

[brent-hoover]

I pulled everything having to do with job control: the package, all jobs, all imports, etc. same error.

[spencern]

I've seen this error as well. Frequently on the 0.18.0 branch and every once in a while on the 0.17.0 branch (GetOutfitted Fork)

[aaronjudd]

We've also not seen this in a production build, nor reported on Linux, which continues point at file watching and the various Meteor issues around this, paired with the number of files we're building -> the issue does seem to happen more frequently the more rebuilding/restarting that's happening.

[spencern]

I've also never seen this in either of our deployed instances on either Digital Ocean or AWS, so I agree that it seems to be an issue with local development/meteor

[aaronjudd]

This has re-emerged in new Meteor issue: meteor/meteor#8648 maybe this time, it'll get some attention. It might not be the same issue or multiple issues but the described behavior of dying with an abort trap 6 is the masked behavior here as well.

[scottcwilson]

Just installed and got this error after running for about 15 mins. Here's my version information:

Node: 8.0.0
NPM: 5.0.0
Meteor Node: 4.8.3
Meteor NPM: 4.6.1
Reaction CLI: 0.10.2
Reaction: 1.3.0
Reaction branch: master
Docker: 17.05.0-ce

If this helps, my mail configuration hadn't been set so I was getting a series of

07:05:46.634Z WARN Reaction: Reaction.Email.getMailUrl() - no email provider configured
07:05:46.640Z ERROR Reaction: Mail not configured

[spencern]

@mikemurray has been experimenting with using the latest release candidate for Meteor which to this point looks to mitigate this bug. I can't imagine we'll push it as the official release until it's an official release for Meteor, but if you're fed up with getting toStringed and want to try something try running with Meteor 1.5.1 rc5

meteor update --release 1.5.1-rc.5

[aaronjudd]

Depending on how high you've set your file limits, you may still experience this issue occasionally, but with Meteor 1.5.1 the issue is mostly gone, although not 100%. (Released in Reaction 1.4). Closing this issue as won't fix, (as it's also mostly out of our control, a confirmed core Meteor bug).