Related Issues

• testing: integer divide by zero in predictN #70709 (closed)
• cmd/go: -test.timeout=0 does not cancel go tool's test timeout #18490 (closed)
• runtime/pprof: panic: test timed out after 9m0s #52916 (closed)
• Go bench test never ends #46493 (closed)
• testing: benchmark iteration reports incorrectly #41637 (closed)
• cmd/go: testing on arm64 often time-out #35525 (closed)
• testing: Benchmark, impossibly low ns/op #69417 (closed)
• x/build: runtime package tests consistently fail due to 45 min timeout on darwin-amd64-longtest, only when running via all.bash #60919 (closed)
• runtime: huge performance drops in a timer application #35395 (closed)
• cmd/go: timeout in TestCache* on darwin-amd64-10_12 #35278 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

tests need to pass before benchmarks are run.
you aren't even reaching the benchmark stage.

Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only.

For questions please refer to https://github.com/golang/go/wiki/Questions

tests need to pass before benchmarks are run

Tests are failing due to an integer divide by zero that's happening due to the number of iterations that are running by the benchmarker (0). You can see the test is being run here where we are dividing by the number of iterations that we are executing, but the benchmark is not executing a run.

This strikes me as a bug if I've asked the benchmarker to execute one run and it isn't doing that.

a test TestSchedulingProfile does not run the benchmarker , only benchmark functions do BenchmarkXxx.

does not run the benchmarker

It calls testing.Benchmark within the function, see here

I think you'll have to show a simplified reproducer, the code your pointing at doesn't match your output (line numbers don't match), and a simple test of testing.Benchmark in a test function doesn't support b.N being 0.

It does look like I pointed to the wrong line. Here's the line that's actually throwing the error. I did do a Println on res.N and res.T in my environment and got 0 and 0s respectively. Still trying to get a toy example working but at first glance, those values definitely look suspicous.

Oh! I think I figured it out, it's the b.Fatalf statement here. I was under the impression that this would cause a panic, but looks like this was just causing silent failure from the test that didn't quite point back to the actual cause.