if you give a full reproducer, we can probably help. Without that there's 
nothing we can suggest
except that, "your example works for me". I attached a transcript to this 
playground of what I see when
I run on darwin/amd64 Sonoma with go v1.25.6:

https://go.dev/play/p/oW7HqhC1hzB

On Monday, June 15, 2026 at 8:46:19 PM UTC-3 Tom Limoncelli wrote:

> Thanks for the fast reply!
>
> Sadly GOTRACEBACK=all (and other settings) didn't change the output.  
>  Even GOTRACEBACK=crash did nothing.
>
> The fact that this causes an infinite loop (or maybe a deadlock) indicates 
> this is not the intended behavior.
>
> Tom
>
>
> On Mon, Jun 15, 2026 at 4:25 PM Jason E. Aten <[email protected]> wrote:
>
>> Be sure your env has GOTRACEBACK set to "single" or "all" or "system" 
>> (see https://pkg.go.dev/runtime) and not "none". Panic usually shows the 
>> trace by default, but I suspect t.Run() may be covering it up so I would 
>> try on just a simple raw func TestOne(t *testing.T) {...} first. It is 
>> possible to have some of the layers of test infrastructure hide things from 
>> you, but I couldn't tell you exactly how, so start simple.
>>
>> My usual way to halt a Go program and get a stack trace is to send 
>> SIGQUIT using "pkill -QUIT project.test". 
>>
>> kill -QUIT also kills the program though, which is fine if it is 
>> deadlocked and you are trying to figure out where. But if you want to keep 
>> it alive and look at a goroutine stack snapshot, you can start the program 
>> with pprof sampling as described https://pkg.go.dev/net/http/pprof and 
>> then opening a browser and hitting the port like http://localhost:6060; 
>> if you did:
>>
>> import _ "net/http/pprof"
>> go func() {
>> log.Println(http.ListenAndServe("localhost:6060", nil))
>> }()
>>
>> On Monday, June 15, 2026 at 7:39:29 PM UTC-3 Tom Limoncelli wrote:
>>
>>> Is there a way to get "go test" to display the stack trace when the 
>>> function under test panics?
>>>
>>> I've written a function that (for purposes of this demo) panics if 
>>> passed true:
>>>
>>> https://go.dev/play/p/lGVenZjDRpD
>>>
>>> The output on go playground looks like this:
>>>
>>> === RUN   TestMyFunc
>>> === RUN   TestMyFunc/good
>>> === RUN   TestMyFunc/panic
>>> --- FAIL: TestMyFunc (0.00s)
>>>     --- PASS: TestMyFunc/good (0.00s)
>>>     --- FAIL: TestMyFunc/panic (0.00s)
>>> panic: assignment to entry in nil map [recovered, repanicked]
>>>
>>> goroutine 17 [running]:
>>> testing.tRunner.func1.2({0x55a800, 0x6cac00})
>>> /usr/local/go-faketime/src/testing/testing.go:1974 +0x232
>>> testing.tRunner.func1()
>>> /usr/local/go-faketime/src/testing/testing.go:1977 +0x349
>>> panic({0x55a800?, 0x6cac00?})
>>> /usr/local/go-faketime/src/runtime/panic.go:860 +0x13a
>>> play.MyFunc(...)
>>> /tmp/sandbox252008880/prog_test.go:14
>>> play.TestMyFunc.func1(0x3e938180e008?)
>>> /tmp/sandbox252008880/prog_test.go:33 +0x33
>>> testing.tRunner(0x3e938180e008, 0x3e9381800000)
>>> /usr/local/go-faketime/src/testing/testing.go:2036 +0xea
>>> created by testing.(*T).Run in goroutine 7
>>> /usr/local/go-faketime/src/testing/testing.go:2101 +0x4c5
>>>
>>> Program exited.
>>>
>>> However when I run this on my personal machine (go1.26.4, Macos 26.5.1) 
>>> the system goes into an infinite loop until I press CTRL-C.  At that point 
>>> it exits but never shows the stack trace:
>>>  
>>> $ go test -v 
>>> === RUN   TestMyFunc
>>> === RUN   TestMyFunc/good
>>> === RUN   TestMyFunc/panic
>>> --- FAIL: TestMyFunc (0.00s)
>>>     --- PASS: TestMyFunc/good (0.00s)
>>>     --- FAIL: TestMyFunc/panic (0.00s)
>>> ^Csignal: interrupt
>>> FAIL ptest 4.924s
>>>
>>>
>>> As you can imagine, debugging an unknown panic is difficult without the 
>>> stack trace indicating the problematic line.  Delve has the same behavior.
>>>
>>> Is there a way to have "go test" display the stack trace like Go 
>>> playground does?
>>>
>>> Also... the fact that a panic sends Go testing into an infinite loop 
>>> sounds like a bug.  Is this just my environment, or can others reproduce 
>>> this?
>>>
>>> Thanks in advance!
>>> Tom
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected].
>> To view this discussion visit 
>> https://groups.google.com/d/msgid/golang-nuts/216b0486-4520-4b5f-a2e4-6286e494772fn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/216b0486-4520-4b5f-a2e4-6286e494772fn%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/golang-nuts/3fef7b0f-55d0-4d80-95f9-dafdc82a0287n%40googlegroups.com.

Reply via email to