I can't reproduce it on linux/amd64 on either tip nor 1.8.1, so likely related to Windows.

@mvdan Yes, it's ok on Linux. I only test it on Windows and linux, and linux is ok.

No idea why this fails on Windows. The fix for #3934 (https://golang.org/cl/7322083) was not OS-specific. Somebody with a Windows system will have to debug what is happening.

/cc @alexbrainman

the runtime.main function not enter gopark branch at all if there is no panic information output.

if panicking != 0 {
		println("main.main park")
		gopark(nil, nil, "panicwait", traceEvGoStop, 1)
	}

	print("main.main exit with panicking : ", panicking, "\n")

i modify runtime.main like this, and when no panic information,
println("main.main park") is not output
and print("main.main exit with panicking : ", panicking, "\n") print 0 or 1 randomly.
@ianlancetaylor so i think this issue is not the same as 3934.

Thanks for looking into it. I think I see the problem, but I don't understand why it only appears on Windows. The problem is that calling panic runs deferred functions before setting the runtime package variable panicking. It has to be that way, because we only want to set panicking if we are going to exit, but if a deferred function recovers the panic then we will not exit. In this case the deferred function is wg.Done, and calling it permits wg.Wait to complete, and thus permits main to exit.

I can't quite decide how important it is to fix this problem.

yes, i doubt it also for that only appears on Windows, today i check it on linux again and it's ok.
dose we can add a userpanicing for user's panic call, and inc it immediately after enter gopanic, and dec it after startpanic() or before recover.
and check userpanicing also before check panicing, and call a goparm(). some diff like this:

--- a/src/runtime/panic.go
+++ b/src/runtime/panic.go
@@ -412,6 +412,9 @@ func printpanics(p *_panic) {

 // The implementation of the predeclared function panic.
 func gopanic(e interface{}) {
+       lock(&userpaniclk)
+       atomic.Xadd(&userpanicing, 1)
+       unlock(&userpaniclk)
        gp := getg()
        if gp.m.curg != gp {
                print("panic: ")
@@ -516,6 +519,9 @@ func gopanic(e interface{}) {
                        // Pass information about recovering frame to recovery.
                        gp.sigcode0 = uintptr(sp)
                        gp.sigcode1 = pc
+                       lock(&userpaniclk)
+                       atomic.Xadd(&userpanicing, -1)
+                       unlock(&userpaniclk)
                        mcall(recovery)
                        throw("recovery failed") // mcall should not return
                }
@@ -526,7 +532,13 @@ func gopanic(e interface{}) {
        // the world, we call preprintpanics to invoke all necessary Error
        // and String methods to prepare the panic strings before startpanic.
        preprintpanics(gp._panic)
+       println("gopanic: start panic")
        startpanic()
+
+       lock(&userpaniclk)
+       atomic.Xadd(&userpanicing, -1)
+       unlock(&userpaniclk)
+

--- a/src/runtime/proc.go
+++ b/src/runtime/proc.go
@@ -191,10 +191,22 @@ func main() {
        // another goroutine at the same time as main returns,
        // let the other goroutine finish printing the panic trace.
        // Once it does, it will exit. See issue 3934.
+       lock(&userpaniclk)
+       println("check userpanicing")
+       if userpanicing != 0 {
+               unlock(&userpaniclk)
+               gopark(nil, nil, "panicwait", traceEvGoStop, 1)
+       } else {
+               unlock(&userpaniclk)
+       }
+       println("main.main is exit now, check paniking start, ", panicking)
        if panicking != 0 {
+               println("main.main park")
                gopark(nil, nil, "panicwait", traceEvGoStop, 1)
        }

+       print("main.main exit with panicking : ", panicking, "\n")
+

--- a/src/runtime/runtime2.go
+++ b/src/runtime/runtime2.go
@@ -750,6 +750,9 @@ var (

        goarm                uint8 // set by cmd/link on arm systems
        framepointer_enabled bool  // set by cmd/link
+
+       userpaniclk  mutex
+       userpanicing uint32

I don't know dose it ok on recover.
but i test this on the origin error code mentioned before, it's ok.

and we check dose main.main is exit when recover, if it is, change runtime.mian to run again.

I think I see the problem, but I don't understand why it only appears on Windows.

I tried to debug this a little. I see 2 threads racing to exit process:

1. runtime.dopanic_m is ending with runtime.exit(2)
2. runtime.main is ending with runtime.exit(0)

@ianlancetaylor if you have some things for me to try, let me know.

Alex

@alexbrainman Can you see if https://golang.org/cl/41052 fixes the problem on Windows?

I was able to recreate the problem on GNU/Linux by adding a runtime.Gosched in the deferred function.

This might be too much mechanism for a racy program. We'll see what other people think.

Can you see if https://golang.org/cl/41052 fixes the problem on Windows?

Yes, that fixes this issue here. Thank you.

This might be too much mechanism for a racy program.

I feel the same. Let Austin decide if it is worth it.

Alex

@alexbrainman @ianlancetaylor
if we have three threads, A is for main function, B is for panicking goroutinue, C is for continue main.
C continued A while B is panicking and enter recover not yet.
then A get a chance to run and main will exit 0 before B's panic information can output.

but i think this will hard to appear.

@sydnash Yes. The program is racy.

CL https://golang.org/cl/41052 mentions this issue.