Nil pointer dereference panic

[jeremydonahue]

Got a nil pointer dererence panic. #421 alludes to this but I haven't verified if that's the cause yet. If I have time tomorrow and no one beats me to it, I'll have a crack at fixing it.

runtime error: invalid memory address or nil pointer dereference
runtime.gopanic:1038
runtime.panicmem:221
runtime.sigpanic:735
github.com/prometheus/client_golang/prometheus.(*CounterVec).WithLabelValues:250
sigs.k8s.io/aws-iam-authenticator/pkg/token.tokenVerifier.Verify:528

[jyotimahapatra]

This is different from https://github.com/kubernetes-sigs/aws-iam-authenticator/issues/421 This one looks like happening with WithLabelValues ..which flow are you hitting the nil pointer in?

[vanzin]

if it helps here what we get...

2022/04/11 13:24:53 http: panic serving 127.0.0.1:55144: runtime error: invalid memory address or nil pointer dereference
goroutine 221 [running]:
net/http.(*conn).serve.func1()
        /home/vanzin/.asdf/installs/golang/1.17.5/go/src/net/http/server.go:1802 +0xb9
panic({0x24cd6c0, 0x452e3d0})
        /home/vanzin/.asdf/installs/golang/1.17.5/go/src/runtime/panic.go:1047 +0x266
github.com/prometheus/client_golang/prometheus.(*CounterVec).WithLabelValues(0xc00081ceb0, {0xc0006fcc80, 0x1, 0x6})
        /work/go/pkg/mod/github.com/prometheus/[email protected]/prometheus/counter.go:250 +0x1d
sigs.k8s.io/aws-iam-authenticator/pkg/token.tokenVerifier.Verify({0xc001081830, {0x294f48c, 0x2941b24}, 0xc0010817a0}, {0xc00065e800, 0x749})
        /work/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/token/token.go:540 +0x1525

Everything after that is our code. We're on 0.5.3 which doesn't have this problem, but can't upgrade.

[jeremydonahue]

Hi, we're still getting this panic as of 0.5.7. Here's the most recent stack trace (looks the same as before):

runtime.gopanic:1038
runtime.panicmem:221
runtime.sigpanic:735
github.com/prometheus/client_golang/prometheus.(*CounterVec).WithLabelValues:250
sigs.k8s.io/aws-iam-authenticator/pkg/token.tokenVerifier.Verify:540

@jyotimahapatra It looks like you had a fix for this but where asked to separate it into a different PR. Have you had a chance to do that? We can't upgrade our version of aws-iam-authenticator until this is fixed, and every time someone runs the script to update our modules it breaks a pretty critical infrastructure service once deployed. Let me know if you still want me to elaborate on the flow/usage where we run into this (assuming you don't need it because you seemed to have a fix already).

[jyotimahapatra]

i didnt merge the fix i thought could fix it. Please do the flow where you hit the issue

[jeremydonahue]

Here's some code that reproduces it for me:

package main

import (
	"fmt"
	"os"

	"github.com/aws/aws-sdk-go/aws/endpoints"
	"sigs.k8s.io/aws-iam-authenticator/pkg/token"
)

func main() {
	gen, err := token.NewGenerator(true, false)
	if err != nil {
		fmt.Printf("ERROR: %v\n", err)
		os.Exit(1)
	}

	tok, err := gen.GetWithOptions(&token.GetTokenOptions{ClusterID: "foobar"})
	if err != nil {
		fmt.Printf("ERROR: %v\n", err)
		os.Exit(1)
	}

	verifier := token.NewVerifier("foobar", endpoints.AwsPartitionID)
	_, err = verifier.Verify(tok.Token)
	if err != nil {
		fmt.Printf("ERROR: %v\n", err)
		os.Exit(1)
	}
}

The output is:

❯ go run /tmp/aws-iam-authenticator.go
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xaa717d]

goroutine 1 [running]:
github.com/prometheus/client_golang/prometheus.(*CounterVec).WithLabelValues(0xc000619a00, {0xc00061e120, 0x1, 0x6})
	/home/jeremy/src/go/pkg/mod/github.com/prometheus/[email protected]/prometheus/counter.go:250 +0x1d
sigs.k8s.io/aws-iam-authenticator/pkg/token.tokenVerifier.Verify({0xc000391560, {0xbee34f, 0xc000391560}, 0xc0003914d0}, {0xc000413000, 0x716})
	/home/jeremy/src/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/token/token.go:540 +0x1525
main.main()
	/tmp/aws-iam-authenticator.go:25 +0x147
exit status 2

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[jeremydonahue]

/remove-lifecycle stale

[jeremydonahue]

I went ahead and submitted pull request #477 to fix this. There are a number of ways to handle this, and this is just the one I went with. If there's a different way that you would prefer to do it, I'm happy to do that instead.

[jeremydonahue]

Pull request #477 fixes this and has been merged. I'll close this ticket once a release has been made that includes the fix.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.