From 9fc8fe026baab9959459256f2d47f4bbf21d405a Mon Sep 17 00:00:00 2001 From: Dmitry Vyukov Date: Mon, 21 Oct 2024 11:53:44 +0200 Subject: executor: better handling for hanged test processes Currently we kill hanged processes and consider the corresponding test finished. We don't kill/wait for the actual test subprocess (we don't know its pid to kill, and waiting will presumably hang). This has 2 problems: 1. If the hanged process causes "task hung" report, we can't reproduce it, since the test finished too long ago (manager thinks its finished and discards the request). 2. The test process still consumed per-pid resources. Explicitly detect and handle such cases: Manager keeps these hanged tests forever, and we assign a new proc id for future processes (don't reuse the hanged one). --- pkg/repro/repro.go | 2 ++ 1 file changed, 2 insertions(+) (limited to 'pkg/repro') diff --git a/pkg/repro/repro.go b/pkg/repro/repro.go index d2076ffbf..67171a368 100644 --- a/pkg/repro/repro.go +++ b/pkg/repro/repro.go @@ -262,6 +262,8 @@ func (ctx *reproContext) extractProg(entries []*prog.LogEntry) (*Result, error) var toTest []*prog.LogEntry if ctx.crashExecutor != nil { for _, entry := range entries { + // Note: we don't check ProcID b/c hanged programs are assigned fake unique proc IDs + // that don't match "Comm" in the kernel panic message. if entry.ID == ctx.crashExecutor.ExecID { toTest = append(toTest, entry) ctx.reproLogf(3, "first checking the prog from the crash report") -- cgit mrf-deployment