Segmentation fault when starting dashboard using nonexistent profile

[bitfactory-henno-schooljan]

When I try to launch the Kubernetes dashboard using a profile that does not exist, the process segfaults. This also happens without the -p option when no profiles do not yet exist (e.g. after a fresh install) and it tries to use the default minikube one. The expected response should be that the profile does not exist, which does happen correctly with a command like minikube ip.

The exact command to reproduce the issue:

minikube dashboard -p nonexistent

The full output of the command that failed:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x178 pc=0x1e00e9c]

goroutine 1 [running]:
k8s.io/minikube/cmd/minikube/cmd.glob..func5(0x2e828c0, 0xc000173520, 0x0, 0x2)
	/app/cmd/minikube/cmd/dashboard.go:62 +0x12c
github.com/spf13/cobra.(*Command).execute(0x2e828c0, 0xc0001734c0, 0x2, 0x2, 0x2e828c0, 0xc0001734c0)
	/go/pkg/mod/github.com/spf13/[email protected]/command.go:757 +0x2ae
github.com/spf13/cobra.(*Command).ExecuteC(0x2e83960, 0x1, 0x1ee3ea0, 0xc0000cf948)
	/go/pkg/mod/github.com/spf13/[email protected]/command.go:843 +0x2ec
github.com/spf13/cobra.(*Command).Execute(...)
	/go/pkg/mod/github.com/spf13/[email protected]/command.go:791
k8s.io/minikube/cmd/minikube/cmd.Execute()
	/app/cmd/minikube/cmd/root.go:103 +0x2e
main.main()
	/app/cmd/minikube/main.go:44 +0xcf

The output of the minikube logs command:
No logs seem to get written for this session, process crashes.

The operating system version:
macOS 10.14.5
minikube 1.1.0
VirtualBox 6.0.4

[tstromberg]

Thanks for the bug report! Based on the backtrace, this is the line that crashed:

https://github.com/kubernetes/minikube/blob/master/cmd/minikube/cmd/dashboard.go#L62

I'm confused as to why the config loaded without an error, but the nil pointer dereference is because we aren't checking if either cc or cc.KubernetesConfig is nil. One possible fix may be to move the cluster.EnsureMinikubeRunningOrExit(api, 1) call to be before proxy.ExcludeIP is called.

Help wanted! I'll be happy to review any PR that fixes this.

[medyagh]

thanks for catching it ! I was able to reproduce this bug.

[fenglixa]

@tstromberg @medyagh Could I take this issue? Thanks

[medyagh]

Issue resolved by #4396 thanks to @fenglixa