test: define and test validity of core-dumps

[refack]

• Version: *
• Platform: *
• Subsystem: test,process

The ad-hoc situation is that node has incorporated V8's --abort-on-uncaught-exception as a core feature (Ref: #14013).
There seems to be a consensus forming to make this an explicit design decision and document it (Ref: #13931).

Currently the test suite only tests for process exit state (i.e. code and signal) but does not do any testing on the validity of generated code-dump.

I suggest we define the minimal requirements needed from the core-dump to be valid and find a way to automatically assert those.

/cc @nodejs/post-mortem @nodejs/testing @nodejs/release @nodejs/build

[cjihrig]

FWIW, the llnode test suite generates core files using --abort-on-uncaught-exception, loads them into lldb, and executes commands. Since that project lives under the nodejs org, IMO that should be enough validation.

[richardlau]

AFAIK llnode/lldb doesn't yet cover all of our supported platforms.

[richardlau]

For the platforms it does cover, see nodejs/build#777 about adding CI for llnode.

[refack]

FWIW, the llnode test suite generated core files using --abort-on-uncaught-exception, loads them into lldb, and executes commands. Since that project lives under the nodejs org, IMO that should be enough validation.

Great!

I'll see what can be done for Windows.

[Trott]

@refack Should this remain open?

[joyeecheung]

FWIW I don't see the point of testing core dump generation. The flag triggers a fatal error, whether that leads to a core dump being written to disk and whether the core dump is properly generated depend on the configuration of the system. If there is a bug in the core dump generation, it's unlikely that we can fix it here.

[gireeshpunathil]

agreed - lot of dependancies on user limits, OS limits and file system space. Plus I never came across a user problem in terms of the flag not working. I suggest closing and revisiting if it is an issue.