#!watchflakes
post <- pkg == "runtime" && test == "TestMemPprof"

Issue created automatically to collect these failures.

Example (log):

--- FAIL: TestMemPprof (0.01s)
    crash_test.go:537: signal: trace/breakpoint trap (core dumped)

watchflakes

Comment From: gopherbot

Found new dashboard test flakes for:

#!watchflakes
post <- pkg == "runtime" && test == "TestMemPprof"
2023-06-20 18:25 linux-amd64-longtest go@8484f2fe runtime.TestMemPprof (log) --- FAIL: TestMemPprof (0.01s) crash_test.go:537: signal: trace/breakpoint trap (core dumped)

watchflakes

Comment From: bcmills

See also #57149.

Comment From: mknyszek

This is notably in the maymorestack=mayMoreStackMove section (https://github.com/golang/go/issues/57149 also is, but mentioning it explicitly).

Comment From: mknyszek

In triage, it's very weird that we got a SIGTRAP here. Timeout should be sending a SIGQUIT (or a SIGKILL if SIGQUIT is blocked). If we collected core dumps from builders, this would be a bit easier to figure out. (#49165)

Comment From: mknyszek

@prattmic suggests that maybe we jumped to the wrong address, because we pad functions with int $3.

Comment From: mknyszek

To get more information, Cherry is going to change the test runner in this case to actually dump whatever the subprocess that failed here wrote to stdout/stderr. Right now we have very little to go on.

Comment From: gopherbot

Change https://go.dev/cl/507978 mentions this issue: runtime: print output on failure in TestMemPprof

Comment From: mknyszek

We haven't seen this in over a year since we added the debug print. If it happens again we'll get a new issue.