OSX 10.8 "Abort trap: 6"

[jwerre]

Node crashes at random interval with an "Abort trap: 6" in OSX Mountain Lion (10.8.2)

[AvianFlu]

While doing what?

Abort trap: 6 usually indicates a failed assertion. What other details can you provide?

[jwerre]

I can tell you that I'm using supervisor and coffeescript. Other than that I don't get any other output other than "Abort trap 6". I do have the same app running on an Ubuntu server and haven't seen the error.

[bnoordhuis]

More details would help.

• What version of node?
• What does node -pe process.versions print?
• Are you using any native add-ons, directly or indirectly?
• What does the backtrace in gdb look like?

By "failed assertion", are you suggesting that I have a memory leak?

No. Assertions are run-time sanity checks in the C and C++ code.

[alax]

I just ran into this same issue on Mountain Lion, and I am also using Supervisor. The thing to note is that my Node application didn't crash, just the Supervisor wrapper, so I assume Supervisor is what is throwing the error.

[bnoordhuis]

Hm, no follow-up from the OP in over three months. Closing.

[danfinlay]

I also was getting this problem, also using Supervisor, just upgraded to v.0.10. This is probably a Supervisor problem indeed.

[medikoo]

@FlySwatter such error can only be the cause of some mishandling in C++ code. I believe it should never be result of plain JS operations (@bnoordhuis correct me if I'm wrong) and supervisor is plain JS.

I had once similar issues when using watch functionality on many files, it was permanent on OSX when using Node v0.6.x (exactly same Abort trap: 6 error), but then it was fixed with v0.8.

I take it's a Node issue, but still, exact recipe on how to reproduce that (best if smallest possible test case) would be welcome, without that it's nearly impossible to track it down.

[bnoordhuis]

such error can only be the cause of some mishandling in C++ code. I believe it should never be result of plain JS operations

That is correct provided the JS code doesn't mess around with internals (e.g. the _handle property on a net.Socket object).

The reported issue is too light on details to act on though. At the very least, we'll need a test case or a (gdb) backtrace.

[sandro-pasquali]

This will do it:

var intervalId = setInterval(function() {}, 1);
process.nextTick(intervalId.unref);

Assertion failed: (args.Holder()->InternalFieldCount() > 0), function Unref, file ../src/handle_wrap.cc, line 78.
Abort trap: 6

OSX 10.8.2
Node 0.10.0

[medikoo]

Confirmed, on my side it outputs:

Assertion failed: (args.Holder()->InternalFieldCount() > 0), function Unref, file ../src/handle_wrap.cc, line 78.
Abort trap: 6

[Fauntleroy]

Had this happen to me just now. Had an Express server listening and a couple chokidar watches going.

[bnoordhuis]

Fixed in 22533c0.

[trevnorris]

@bnoordhuis pretty sure you meant to comment, not comment and reopen. :)

[kof]

node -v v0.10.9

Assertion failed: (!uv__io_active(&stream->io_watcher, UV__POLLOUT) || !ngx_queue_empty(&stream->write_completed_queue) || !ngx_queue_empty(&stream->write_queue) || stream->shutdown_req != NULL || stream->connect_req != NULL), function uv_read_stop, file ../deps/uv/src/unix/stream.c, line 1329.
Abort trap: 6

P.S. not using supervisor

[trevnorris]

@kof v0.10.10 is out. try it w/ latest please.

[kof]

doesn't seem to come any more on 0.10.10 ...

[kof]

got it again

Assertion failed: (!uv__io_active(&stream->io_watcher, UV__POLLOUT) || !ngx_queue_empty(&stream->write_completed_queue) || !ngx_queue_empty(&stream->write_queue) || stream->shutdown_req != NULL || stream->connect_req != NULL), function uv_read_stop, file ../deps/uv/src/unix/stream.c, line 1329.
Abort trap: 6

[kof]

getting it right now, constantly reproducible

[kof]

we should do something to nail it as long as it is easy to reproduce

[medikoo]

@kof Can you prepare a good test case, that reproduce that? I believe nobody from Node.js team will try too guess what is happening without that.

[kof]

right now its a running application with all its dependencies, I can try to track down by commenting line by line out, I just thought somebody can propose a faster approach.

[medikoo]

@kof I think there's no faster approach :)

[cspro]

+1 while using Grunt and leaving it overnight.

[Elyx0]

+1 while using express / webpack

[dmt0]

+1 express / webpack
happens often after I introduced a setInterval() call to my app:
node v5.5.0

[hliyan]

+1 webpack

[gabssnake]

Seeing this on Mac OS X 10.11.4, with Node v5.6, webpack 1.10.5 and webpack-dev-server 1.10.1

[daviwil2]

node 4.3.1, Mac OS X 10.11.3, express 4.13.3, not using webpack. Regularly get Abort trap: 6, about 50% of the time the underlying app keeps running and I have to kill it, 50% it dies. This has been consistent across upgrades of node from 10.x and OS X 10.9, 10.10 and earlier 10.11s, and express 4.x. I don't see this on my ubuntu production system running the same versions of node, express etc.

[ChALkeR]

@daviwil2 Is this reported to https://github.com/nodejs/node? Are you using any native modules?

[daviwil2]

Not reported no. Happy to do that if wanted. Native modules, as in extensions to node/V8 written in C++? No, not using any - just standard JS components added via npm.

[alexilyaev]

+1 Happens often while running "webpack-dev-server": "1.14.1" during development on Mac OS X 10.11.4 with Node v5.7.0.

This is what I usually see:

Child html-webpack-plugin for "index.html":
    chunk    {0} index.html 380 bytes
         + 1 hidden modules
Abort trap: 6

Running it using npm start:

"scripts": {
    "prestart": "npm install",
    "start": "webpack-dev-server --hot --progress"
  },

And I have ESLint setup as a preloader in the Webpack config.

[nitruxa]

+1

webpack: bundle is now VALID.
Abort trap: 6

Aborts after some time. Mac OS X 10.11.4, running through npm

[timothyallan]

+1 here as well, same error/OS as @nitruxa with node 6.1.0

Usually happens after I leave the dev machine for a while and I bring it out of screensaver.

[cv]

I'm seeing this in node 6.1.0 on El Capitan, with the following pe process.versions:

{ http_parser: '2.7.0',
  node: '6.1.0',
  v8: '5.0.71.35',
  uv: '1.9.0',
  zlib: '1.2.8',
  ares: '1.10.1-DEV',
  icu: '56.1',
  modules: '48',
  openssl: '1.0.2h' }

[indutny]

@cv may I ask you to do this?

brew install llnode
ulimit -c unlimited
node aborting-script.js
ulimit -c 0
lldb -c /cores/*
# Once in lldb
v8 bt

[freesteph]

I experienced this error message after switching to Node 0.6, I'm not sure it's the exact same issue (see nodejs/node#6563) but it has been fixed for me. Until Node updates its libuv dependency, I made a branch with the fix rebased on node 0.6.x that I used with brew to install: [email protected]:freesteph/node.git#fix/libuv. Hope it helps.

[sspilleman]

Seeing it also / still on

{ http_parser: '2.7.0',
  node: '6.2.0',
  v8: '5.0.71.47',
  uv: '1.9.1',
  zlib: '1.2.8',
  ares: '1.10.1-DEV',
  icu: '57.1',
  modules: '48',
  openssl: '1.0.2h' }

[evanlucas]

@sspilleman can you please open an issue at https://github.com/nodejs/node with some more information? A script to reproduce this would be fantastic. Thanks!

[JeffML]

I'm getting similar errors:

./runTests.sh: line 14: 39479 Abort trap: 6           jasmine-node $f --junitreport --config server $1 --output "reports/${output}"
./runTests.sh: line 14: 39483 Abort trap: 6           jasmine-node $f --junitreport --config server $1 --output "reports/${output}"
./runTests.sh: line 14: 39484 Abort trap: 6           jasmine-node $f --junitreport --config server $1 --output "reports/${output}"
./runTests.sh: line 14: 39485 Abort trap: 6           jasmine-node $f --junitreport --config server $1 --output "reports/${output}"
./runTests.sh: line 14: 39486 Abort trap: 6           jasmine-node $f --junitreport --config server $1 --output "reports/${output}"

The culprit line in my node js app seems to be:

   var test = spawn("./runTests.sh", [url, server.nick], {
        cwd : frisbyRoot,
        stdio : [0, fs.openSync(outfile, "a"), //stdio
        fs.openSync(outfile, "a") //stderr
        ]
    });

The script itself is:

#!/bin/bash

if [[ $# -ne 2 ]]; then
  echo "Usage: $0 URL NICKNAME" >&2
  exit 1
fi

#FILES=./*_spec.js

FILES=`find . -name "*_spec.js"`

output=$2

for f in $FILES
do
jasmine-node $f --junitreport --config server $1 --output "reports/${output}"
done

version info:
Jeffs-WebTesting-MacBook-Pro:tests test$ npm ls -depth=0
[email protected] /Users/test/unit-tests/frisby/tests
├── [email protected]
├── [email protected]
├── [email protected]
└── [email protected]

Jeffs-WebTesting-MacBook-Pro:tests test$ npm -g ls -depth=0
/opt/local/lib
├── [email protected]
├── [email protected]
└── [email protected]

node version: 4.4.3

Verified that I can run the jasmine tests from the command line via runTests.sh without error.

[antoinerousseau]

I'm getting the same error with webpack 1.13.1 and node 6:

Child html-webpack-plugin for "index.html":
        + 3 hidden modules
Abort trap: 6
$ 
$ node -pe process.versions
{ http_parser: '2.7.0',
  node: '6.2.2',
  v8: '5.0.71.52',
  uv: '1.9.1',
  zlib: '1.2.8',
  ares: '1.10.1-DEV',
  icu: '57.1',
  modules: '48',
  openssl: '1.0.2h' }

[indutny]

Any chance anyone could get a core file by running ulimit -c unlimited before it will crash? Having one would help us significantly!

[dmt0]

BTW, haven't seen this issue reoccurring since a recent upgrade.

[evoL]

@indutny I managed to prepare a nice, 2GB core dump when the issue occured. I was running an express server with the webpack middleware. I'm on OS X 10.11.6.

$ node -pe process.versions
{ http_parser: '2.7.0',
  node: '6.2.2',
  v8: '5.0.71.52',
  uv: '1.9.1',
  zlib: '1.2.8',
  ares: '1.10.1-DEV',
  icu: '57.1',
  modules: '48',
  openssl: '1.0.2h' }

I looked at it and, from my very limited understanding, the only thing that I think might be relevant is this backtrace:

* thread #10: tid = 0x0009, 0x00007fff823a9f06 libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGSTOP
  * frame #0: 0x00007fff823a9f06 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff985404ec libsystem_pthread.dylib`pthread_kill + 90
    frame #2: 0x00007fff85c736df libsystem_c.dylib`abort + 129
    frame #3: 0x0000000100704f8b node`uv_cond_wait + 20
    frame #4: 0x00000001006f8b90 node`worker + 228
    frame #5: 0x0000000100704be5 node`uv__thread_start + 25
    frame #6: 0x00007fff9853d99d libsystem_pthread.dylib`_pthread_body + 131
    frame #7: 0x00007fff9853d91a libsystem_pthread.dylib`_pthread_start + 168
    frame #8: 0x00007fff9853b351 libsystem_pthread.dylib`thread_start + 13

Please contact me if you need the core file or any other details.

[karna41317]

Any update on this crash. ???

$node -pe process.versions

{ http_parser: '2.7.0',
  node: '6.9.1',
  v8: '5.1.281.84',
  uv: '1.9.1',
  zlib: '1.2.8',
  ares: '1.10.1-DEV',
  icu: '57.1',
  modules: '48',
  openssl: '1.0.2j' }

[brendonco]

@karna41317 I have the same issue with you. process.versions same as yours.

[kosiakMD]

+1
Mac OS Sierra
{ http_parser: '2.7.0',
node: '7.5.0',
v8: '5.4.500.48',
uv: '1.10.2',
zlib: '1.2.8',
ares: '1.10.1-DEV',
modules: '51',
openssl: '1.0.2k',
icu: '58.2',
unicode: '9.0',
cldr: '30.0.3',
tz: '2016j' }

[yilinglu]

Still have this issue while using BrowserSync
{ http_parser: '2.7.0', node: '6.9.5', v8: '5.1.281.89', uv: '1.9.1', zlib: '1.2.8', ares: '1.10.1-DEV', icu: '57.1', modules: '48', openssl: '1.0.2k' }

[gibfahn]

@yilinglu please raise an issue with the browsersync module, or in nodejs/node if you think it's a problem with Node itself. This repo is archived and not maintained.

[dehimer]

I got same issue when updated node/npm to last and not restarted angular2 in terminal. That happened after 10 minutes (mb no sense in interval).

[emmya]

+1 running express/webpack, El Capitan

{ http_parser: '2.7.0',
  node: '7.7.2',
  v8: '5.5.372.41',
  uv: '1.11.0',
  zlib: '1.2.11',
  ares: '1.10.1-DEV',
  modules: '51',
  openssl: '1.0.2k',
  icu: '58.2',
  unicode: '9.0',
  cldr: '30.0.3',
  tz: '2016j' }

[gibfahn]

This repo is archived and not maintained.

Please raise an issue with the module, or in nodejs/node if you think it's a problem with Node itself.