goroutine-leak | an example for debuging golang goroutine leak | Code Inspection library

Here, in the Go Playground, is your original code with a few slight modifications:

• the delays are reduced, except for time.Sleep(5) which becomes time.Sleep(time.Second);
• a return is removed because it becomes unnecessary;
• a fmt.Println is commented out, because with both the return and the uncommented fmt.Println, go vet complains about the unreachable fmt.Println;
• the channel stored in errChang is changed to unbuffered.

When run, its output is:

The problem with your code is twofold.

First, there is, theoretically, a goroutine leak since any attempt to send a value to a channel with zero capacity (an unbuffered channel or a filled up buffered channel) blocks the sending goroutine until a receive operation is done on that channel.

So, yes, by definition of how channels work, all your three goroutines will be blocked in the numChan <- num statement.

Second, since some revision of Go, an unhandled panic by default dumps only the stack trace of the panicking goroutine. If you wish to dump the stacks of all the active goroutines, you'd have to tweak the runtime — from the documentation of the package runtime:

The GOTRACEBACK variable controls the amount of output generated when a Go program fails due to an unrecovered panic or an unexpected runtime condition. By default, a failure prints a stack trace for the current goroutine, eliding functions internal to the run-time system, and then exits with exit code 2. The failure prints stack traces for all goroutines if there is no current goroutine or the failure is internal to the run-time. GOTRACEBACK=none omits the goroutine stack traces entirely. GOTRACEBACK=single (the default) behaves as described above. GOTRACEBACK=all adds stack traces for all user-created goroutines. GOTRACEBACK=system is like “all” but adds stack frames for run-time functions and shows goroutines created internally by the run-time. GOTRACEBACK=crash is like “system” but crashes in an operating system-specific manner instead of exiting. For example, on Unix systems, the crash raises SIGABRT to trigger a core dump. For historical reasons, the GOTRACEBACK settings 0, 1, and 2 are synonyms for none, all, and system, respectively. The runtime/debug package's SetTraceback function allows increasing the amount of output at run time, but it cannot reduce the amount below that specified by the environment variable. See https://golang.org/pkg/runtime/debug/#SetTraceback.

Also note that you must not ever use timers for (simulating) synchronization: in a toy example this might work but in real life nothing prevents your three goroutines from not having a chance to be run during the time span your main goroutine spent in the call to time.Sleep — so the outcome might be that any number of spawned goroutines had run: from 0 to 3.

Add there the fact that when main exits the runtime merely kills all the outstanding active goroutines, and the result of the test might be surprising at best.

Hence a proper solution would be to

• Merely print the stacks where needed,
• Make sure you synchronize the sends by the matching receives: