| Summary: | sys-apps/portage: AbstractEbuildProcess calls _unexpected_exit when child is killed by SIGINT | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Zac Medico <zmedico> |
| Component: | Core - Ebuild Support | Assignee: | Portage team <dev-portage> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Zac Medico
2018-06-14 19:10:16 UTC
Actually the code already checks if the child was killed by a signal here: > if self.returncode < 0: > if not self.cancelled: > self._killed_by_signal(-self.returncode) So, maybe sandbox it hiding the signal, since relevant output looks like this: > ^Csandbox:stop caught signal 2 in pid 16582 > * The ebuild phase 'prepare' has exited unexpectedly. This type of > * behavior is known to be triggered by things such as failed variable > * assignments (bug #190128) or bad substitution errors (bug #200313). > * Normally, before exiting, bash should have displayed an error message > * above. If bash did not produce an error message above, it's possible > * that the ebuild has called `exit` when it should have called `die` > * instead. This behavior may also be triggered by a corrupt bash binary or > * a hardware problem such as memory or cpu malfunction. If the problem is > * not reproducible or it appears to occur randomly, then it is likely to > * be triggered by a hardware problem. If you suspect a hardware problem > * then you should try some basic hardware diagnostics such as memtest. > * Please do not report this as a bug unless it is consistently > * reproducible and you are sure that your bash binary and hardware are > * functioning properly. The signal is intended to pass through sandbox, since this commit: https://gitweb.gentoo.org/proj/sandbox.git/commit/?id=c119fe8e393540224c803ab5036ddb80b800716c |