| Summary: | FEATURES="test" sys-libs/glibc ends in infinite loop with sys-apps/sandbox-1.8 | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Nick Fortino <nfortino> |
| Component: | Sandbox | Assignee: | Sandbox Maintainers <sandbox> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
build.log
process tree Proposed patch |
||
|
Description
Nick Fortino
2009-04-06 08:13:41 UTC
Created attachment 187444 [details]
build.log
The build log, to be exact:
head -n -78413860 build.log | tail -f 600
leaving 6 lines of the repeated ISE.
ugh, i forgot to decode the signal info in the last message too signal 17 is obviously SIGCHLD code 4 is CLD_TRAPPED afaik i'm pretty sure in this case, si_status represents a signal which means 6 is SIGABRT and 11 is SIGSEGV ... the glibc test cases do trigger such signals in the normal run of things (at least, i know SIGABRT is normal). although none of those should cause an infinite hang. the unhandled signal is warned about and life goes on. can you do a `ps` (tree would be best) to see what's hung ? and perhaps gdb it to get a backtrace (although if it's a ptraced child, you wont be able to gdb it) ? Created attachment 187470 [details]
process tree
A portion of ps -eHf, taken during the infinite hang.
looks like the assert test in question segfaults for some reason and sandbox keeps on tracing it forever TRACE (pid=32705):trace_child_signal: got sig SIGCHLD(17): code:CLDTRAPPED(4) status:SIGTRAP(5) TRACE (pid=32705):trace_loop: IDK:rt_sigaction(...) TRACE (pid=32705):trace_child_signal: got sig SIGCHLD(17): code:CLDTRAPPED(4) status:SIGTRAP(5) = -1 (errno: 38: Function not implemented) TRACE (pid=32705):trace_loop: IDK:tgkill(...) TRACE (pid=32705):trace_child_signal: got sig SIGCHLD(17): code:CLDTRAPPED(4) status:SIGABRT(6) = 0 TRACE (pid=32705):trace_child_signal: got sig SIGCHLD(17): code:CLDTRAPPED(4) status:SIGSEGV(11) TRACE (pid=32705):trace_loop: IDK:-1(...) TRACE (pid=32705):trace_child_signal: got sig SIGCHLD(17): code:CLDTRAPPED(4) status:SIGSEGV(11) = 6 ... same thing forever ... Created attachment 187744 [details, diff]
Proposed patch
This looks to be caused by the sandbox not forcefully aborting processes which send fatal signals since commit 7fab636fb34f95cb0e40fbaa13fcdf10cb297abe
Unless I missed something, the only way to get out of trace_loop is with a CLD_KILLED or a CLD_EXITED code, which will never happen if the child calls abort or segfaults. The attached patch calls sb_abort() for the signals I could quickly think of which need a forceful abort (the list is likely not exhaustive).
that would keep sandbox from hitting an infinite loop, but it wouldnt fix the underlying problem issue is that when we're tracing, we get an event for every signal the child receives. unless we tell the child to continue on, the kernel will block delivery of that signal to the child. http://git.overlays.gentoo.org/gitweb/?p=proj/sandbox.git;a=commitdiff;h=0c9500ea1a6dafdb5167c2d11ad47c8fcfff3141 |
