Try to avoid generating a core dump in segfault Proc test #791
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
87f16d9 to
3021f29
Compare
MasterDuke17
approved these changes
Feb 6, 2022
|
This does prevent the actual core file from being created, but there is still an entry in my $p = Proc.new;
use nqp;
nqp::bindattr(nqp::decont($p), Proc, q|$!exitcode|, 0); nqp::bindattr(nqp::decont($p), Proc, q|$!signal|, 11);
use Test;
throws-like { sink $p }, X::Proc::Unsuccessful;This passes for me. |
|
I think I tried that and it still created a coredump |
Huh, doesn't for me (using arch linux). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The test intentionally triggers a segfault. Especially on developer's systems, this will create a core dump that will be listed by e.g.
coredumpctl listwhich makes it harder to notice actual bug-related segfaults. We can avoid this by disabling core dumps for the process. Unfortunately there doesn't seem to be a portable way to do this. The only way to do this without changing the nature of the test (by e.g. running the process through a shell) is to use NativeCall again to callsetrlimitOn the bright side, if the setrlimit call fails (because e.g. it's not available on Windows), we do not need to care, as worst case we revert to the previous behaviour.