test/async-hooks/test-callback-error.js always produces core file

[trevnorris]

• Version: master (f39ad8a), v12.x (b4e670d) back to v12.0.0
• Platform: All
• Subsystem: async_hooks, test

The test test/async-hooks/test-callback-error.js always produces a core file when run.

Example reproduction:

$ ls core
ls: cannot access 'core': No such file or directory
$ ./node test/async-hooks/test-callback-error.js
start case 1
end case 1: 74.522ms
start case 2
end case 2: 79.682ms
start case 3
end case 3: 9.263ms
$ ls core
core

Expected: Successful tests should not produce core files.

The issue comes from case 3 above, which runs:

$ ./node test/async-hooks/test-callback-error.js --abort-on-uncaught-exception test_callback_abort

The problem is test_callback_abort always has an uncaught exception. Here I've changed the test to always print the output from case 3 child's stderr:

$ ./node test/async-hooks/test-callback-error.js
start case 1
end case 1: 51.322ms
start case 2
end case 2: 47.906ms
start case 3
end case 3: 12.985ms
Error: test_callback_abort
    at ActivityCollector.<anonymous> (node/test/async-hooks/test-callback-error.js:27:45)
    at ActivityCollector.oninit node/test/common/index.js:373:15)
    at ActivityCollector._init (node/test/async-hooks/init-hooks.js:192:10)
    at emitInitNative (internal/async_hooks.js:134:43)
    at emitInitScript (internal/async_hooks.js:341:3)
    at new AsyncResource (async_hooks.js:156:7)
    at Object.<anonymous> (node/test/async-hooks/test-callback-error.js:29:5)
    at Module._compile (internal/modules/cjs/loader.js:936:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:947:10)
    at Module.load (internal/modules/cjs/loader.js:790:32)
 1: 0x9837a0 node::Abort() [node]
 2: 0x9edaf9  [node]
 3: 0xb129ad v8::internal::FunctionCallbackArguments::Call(v8::internal::CallHandlerInfo) [/usr/local/bin/node]
 4: 0xb120bb  [node]
 5: 0xb117ed  [node]
 6: 0x123c579  [node]

(note: the above output is from v12.9.0)

Even though, ironically, running the test directly doesn't cause the core file:

$ ./node test/async-hooks/test-callback-error.js --abort-on-uncaught-exception test_callback_abort
assert.js:373
    throw err;
    ^

AssertionError [ERR_ASSERTION]: The expression evaluated to a falsy value:

  assert.ok(!arg)

    at Object.<anonymous> (node/test/async-hooks/test-callback-error.js:34:8)
    at Module._compile (internal/modules/cjs/loader.js:936:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:947:10)
    at Module.load (internal/modules/cjs/loader.js:790:32)
    at Function.Module._load (internal/modules/cjs/loader.js:703:12)
    at Function.Module.runMain (internal/modules/cjs/loader.js:999:10)
    at internal/main/run_main_module.js:17:11 {
  generatedMessage: true,
  code: 'ERR_ASSERTION',
  actual: false,
  expected: true,
  operator: '=='
}

[juanarbol]

@trevnorris I could not replicate that behavior, I checked out to f39ad8a91f, re-compiled node bin; no core file generated.

[Trott]

I also could not replicate on macOS (but did not try very hard so figured it was likely I was doing something wrong, which may still end up being true....)

[addaleax]

I think all that we need to do is to move the test to test/abort, right?

Even though, ironically, running the test directly doesn't cause the core file:

It does when the command line args are in the right order, i.e. with ./node --abort-on-uncaught-exception test/async-hooks/test-callback-error.js test_callback_abort instead of ./node test/async-hooks/test-callback-error.js --abort-on-uncaught-exception test_callback_abort it crashes as expected.

I also could not replicate on macOS (but did not try very hard so figured it was likely I was doing something wrong, which may still end up being true....)

I think it should generate a core file everywhere – the process does fail with SIGABRT and the test checks that – assuming ulimit -c and the core dump paths are set accordingly.

[cjihrig]

FWIW, I am able to generate a core file on macOS by running the test after ulimit -c unlimited.

[Trott]

assuming ulimit -c and the core dump paths are set accordingly.

sigh Yep, forgot I had disabled core dumps entirely. Sorry for the noise. You'd never know I've been using Unix-like operating systems for 30 years.

[juanarbol]

I could work on this with some guidance!

[trevnorris]

It does when the command line args are in the right order [...]

@addaleax Thanks for confirming that.

[bnoordhuis]

@juanarbol I can see two ways of fixing the test:

1. Move it to test/abort
2. Change the test to re-execute itself with ulimit -c 0 so it never writes a core dump

My preference is for (2).

grep 'ulimit -c 0' test/ will find you some examples. There's even a helper function for it, common.childShouldThrowAndAbort().

[juanarbol]

@bnoordhuis I've a question, how can I append 'ulimit -c 0 && ' to fork? I tried by changing execPath param, I did not worked; could I use spawn instead? (I really prefer option number 2) Or maybe continue with option 1...

[bnoordhuis]

@juanarbol see e.g. test/pummel/test-abort-fatal-error.js for an example.

[juanarbol]

@bnoordhuis Sorry, I could not patch this issue, I do not understand very good child process and async hooks, sorry again; maybe later I'll help with this kind of issues, again, thanks for the help and the examples.

PS: I tried to move to abort, It didn't worked

[trevnorris]

Thank you for the fix.

[bnoordhuis]

My pleasure, Trevor. :-)