on fresh system, portage installed dev-lang/go-bootstrap and using it to install dev-lang/go hangs in go version
Created attachment 748329 [details] emerge --info output and basic process info emerge --info output and basic process info
app-emulation/docker-cli-20.10.10 seems to hang for me too when it calls Go(?). I can file a new bug but I figure I'd let some investigation happen here first rather than have a load of dupes: 2021/11/03 22:23:11 WARN: /var/tmp/portage/app-emulation/docker-cli-20.10.10/work/docker-cli-20.10.10/src/github.com/docker/cli/man/src/volume/rm.md does not exist, skipping * Unable to trace children due to YAMA ptrace_scope=1 * Unable to trace children due to YAMA ptrace_scope=1 * Unable to trace children due to YAMA ptrace_scope=1 WARNING: go-md2man does not handle node type HTMLSpan WARNING: go-md2man does not handle node type HTMLSpan WARNING: go-md2man does not handle node type HTMLSpan WARNING: go-md2man does not handle node type HTMLSpan WARNING: go-md2man does not handle node type HTMLSpan * Unable to trace children due to YAMA ptrace_scope=1 * Unable to trace children due to YAMA ptrace_scope=1 * Unable to trace children due to YAMA ptrace_scope=1 * Unable to trace children due to YAMA ptrace_scope=1 * Unable to trace children due to YAMA ptrace_scope=1 * Unable to trace children due to YAMA ptrace_scope=1
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0410a141e0a13133097d422078f5edaf2894dc1a commit 0410a141e0a13133097d422078f5edaf2894dc1a Author: Sam James <sam@gentoo.org> AuthorDate: 2021-11-04 00:31:20 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-11-04 00:32:13 +0000 profiles: mask newer sandbox versions w/ ptrace issues Masking for now to avoid duplicate reports of known issues; hangs when emerging e.g. Firefox and seemingly anything Go based are nasty. One of the bugs (821403) should be OK now but tagging anyway for reference. Bug: https://bugs.gentoo.org/821532 Bug: https://bugs.gentoo.org/821523 Bug: https://bugs.gentoo.org/821403 Signed-off-by: Sam James <sam@gentoo.org> profiles/package.mask | 8 ++++++++ 1 file changed, 8 insertions(+)
I've masked for now just to avoid getting loads more dupes - we had a bunch more reports on #gentoo and the (new) Firefox bug may well be a dupe of this too. Just looking to avoid too much chaos while we figure out what's going on.
(In reply to Sam James from comment #4) > I've masked for now just to avoid getting loads more dupes - we had a bunch > more reports on #gentoo and the (new) Firefox bug may well be a dupe of this > too. Just looking to avoid too much chaos while we figure out what's going > on. (and obviously feel free to drop it when you think it's fixed)
hmm, i handle fork & clone in the same way, but that was before trying to release them as untraceable. i wonder if these programs are using threads and the tracer is getting into a bad state as a result. prob should decode the clone flags and not do anything special if it's just creating a thread ... so use the one-to-many model for threads since they should have the same PID.
i read the docs & played with debug logic a bit more, and i think it's actually OK as-is. from ptrace pov, everything operates on TIDs, not PIDs. i'm able to repro the failure with dev-lang/go inconsistently, so that's annoying. still trying to get a better handle of where it's going wrong. i might put this behind a knob disabling to off until i can, that way we don't block other features & fixes rolling in.
(In reply to SpanKY from comment #7) > i might put this behind a knob disabling to off until i can, that way we > don't block other features & fixes rolling in. would you mind looking into that that if possible?
(In reply to Sam James from comment #8) > (In reply to SpanKY from comment #7) > > i might put this behind a knob disabling to off until i can, that way we > > don't block other features & fixes rolling in. > > would you mind looking into that that if possible? also, i've lost track to be honest, but are we at a point where we reckon 2.29 is ok to stable?
(In reply to Sam James from comment #9) > (In reply to Sam James from comment #8) > > (In reply to SpanKY from comment #7) > > > i might put this behind a knob disabling to off until i can, that way we > > > don't block other features & fixes rolling in. > > > > would you mind looking into that that if possible? > > also, i've lost track to be honest, but are we at a point where we reckon > 2.29 is ok to stable? ping
Obsolete given bug 879087's resolution (moving that code onto a separate branch).
