There's no way to prove it's a false positive without full compilable code. Please provide it.

Anyway, from guessing what the code may look like, I think it's a quite real deadlock.

I think it's a quite real deadlock.

It is not. Reading the docs of t.FailNow, this is an API constraint (only call FailNow from testing goroutine) that the detector does not sort out.
My problem here is that the error message is misleading and people will need hours to figure out that it is not an "actual concurrency problem" of their code.

IMO it should work like this: testing.T.FailNow should set a flag aboutToAbortAndAmNotADeadlock, which the deadlock detector then checks and knows it does not need to run.

It is not.

Show the code. Nothing else matters.

I think you've misinterpreted the FailNow docs. It ends the goroutine (via calling runtime.Goexit), so if there is stuff happening after that point, it won't run. And if the stuff happening after that is what causes your program to NOT deadlock, then you certainly might have a deadlock. It's not possible for the testing package to guarantee the non-existence of bugs elsewhere in your program.

I've tweaked the bug's title a bit and I'll also page some runtime and deadlock folks @aclements @dvyukov, s'il vous plait.

It is not. Reading the docs of t.FailNow, this is an API constraint (only call FailNow from testing goroutine) that the detector does not sort out.

It's not the deadlock detector's responsibility to enforce API constraints. Maybe FailNow should enforce that it's only called from a testing goroutine and give a more useful error if it is not.

My problem here is that the error message is misleading and people will need hours to figure out that it is not an "actual concurrency problem" of their code.

It's obviously hard to say without a more complete code example, but this looks like it is an actual concurrency problem and a very real deadlock. I would expect the traceback to point at the <-done line, which should make you ask why the done <- true never executed. Is this not what happened?

Separately, it's an interesting question whether a deadlock should kill the entire test run or just result in a test failure. But the latter would require a fair amount of new runtime API surface that doesn't seem worth its weight. And it would still report it as a deadlock; it would just keep going with the other tests.

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)