Repository navigation
test: define and test validity of core-dumps #14110
Description
- 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
Activity
cjihrig commentedon Jul 6, 2017
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 commentedon Jul 6, 2017
AFAIK llnode/lldb doesn't yet cover all of our supported platforms.
richardlau commentedon Jul 6, 2017
For the platforms it does cover, see nodejs/build#777 about adding CI for llnode.
refack commentedon Jul 6, 2017
Great!
I'll see what can be done for Windows.
Trott commentedon Jun 7, 2018
@refack Should this remain open?
joyeecheung commentedon Jun 8, 2018
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 commentedon Jun 8, 2018
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.