(attn @timothy-king @zpavlinovic)

The lack of output could possibly be due to an unexpected call to os.Exit from within the Example test.

(The testing package buffers example output for comparison, so if the process exits during an Example its output may be stuck in the buffer.)

Does this issue still appear? I was not able to reproduce it locally (go test) or on slowbot builders (TRY=linux-amd64-longtest).

I've tried creating some illustrative examples where Example abruptly ends using return, panic, and os.Exit. I've always got some output, even for os.Exit.

panic: unexpected call to os.Exit(0) during test [recovered]
        panic: unexpected call to os.Exit(0) during test

It is possible that the issue appears under certain timing conditions (or that I am missing something obvious).

I've also went through callees of Example to see if they use os.Exit. I wasn't able to find anything, but my search wasn't exhaustive tbh.

Any other suggestions for reproducing this?

Does this issue still appear?

There is only one occurrence so far in the logs. This is probably a nondeterministic failure of some sort, or perhaps a bad failure mode of some subprocess being terminated due to memory exhaustion.

If any action is needed atm, should we somehow change this from Example to Test* where we check for string equality rather than relying on Output?

The Example failure mode that I suspect looks something like this:

$ cat main_test.go
package main

import (
        "fmt"
        "os"
)

func Example() {
        fmt.Println("hah!")
        os.Exit(1)

        // Output:
        // hah!
}

$ go test
exit status 1
FAIL    example 0.008s

But it's also entirely possible that the failure was caused by something else in the process. 🤔

Probably the thing to do for now is just wait for clues from any similar failures.

Strange. I don't see any calls to os.Exit (except indirectly via log.Fatal or similar, which prints an error), and in any case the test driver now detects and reports this mistake. The only calls to t.Fail (which prints no message) are after calls to doOneInput, which maintains the invariant that a false result is never returned without an error being printed.

The "Entering directory" message doesn't mean the failure is necessarily in that Test function (as your discussion of Example implicitly acknowledges), but none of the other tests looks suspicious.

I think it's "impossible", which suggests an external event killed the process. I don't think the go/pointer package itself has a fault. Closing this for now. Feel free to reopen if it recurs.