#!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)
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)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.