Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

panic: runtime error: invalid memory address or nil pointer dereference #1186

Open
JoelKle opened this issue Oct 23, 2024 · 1 comment
Open

Comments

@JoelKle
Copy link

JoelKle commented Oct 23, 2024

We run AWX version 24.6.1 using the awx-operator in a k3s cluster.

Inside the awx-task pod the awx-ee container crashed with the following error message:

# kubectl -n awx logs awx-task-77b54f47c6-rbwbq -c awx-ee --previous
DEBUG 2024/10/23 01:10:38 Client connected to control service @
DEBUG 2024/10/23 01:10:38 Control service closed
DEBUG 2024/10/23 01:10:38 Client disconnected from control service @
DEBUG 2024/10/23 01:10:45 Client connected to control service @
DEBUG 2024/10/23 01:10:45 Control service closed
DEBUG 2024/10/23 01:10:45 Client disconnected from control service @
DEBUG 2024/10/23 01:10:47 Sending service advertisement: &{awx-task-77b54f47c6-rbwbq control 2024-10-23 01:10:47.771711122 +0000 UTC m=+1322181.989097998 1 map[type:Control Service] [{local false} {kubernetes-runtime-auth false} {kubernetes-incluster-auth false}]}
INFO 2024/10/23 01:10:49 Detected Error: EOF for pod awx-schwarz/automation-job-975007-sg52t. Will retry 5 more times.
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x16222f5]

goroutine 533140 [running]:
github.com/ansible/receptor/pkg/workceptor.(*KubeUnit).kubeLoggingWithReconnect(0xc000410300, 0x44645d?, 0xc0004ac510, 0xc001016250, 0xc001016260)
	/source/pkg/workceptor/kubernetes.go:388 +0xb55
created by github.com/ansible/receptor/pkg/workceptor.(*KubeUnit).runWorkUsingLogger in goroutine 533086
	/source/pkg/workceptor/kubernetes.go:830 +0xba7

I've not been able to see any memory / cpu overload problems on the node running this pod.

receptor version:

$ receptor --version
1.4.8+d7fe592

Is this a bug in receptor?
Let me know if you need more infos / logs.

Thx Joel

@nmeilick
Copy link

Causative seems to be the use of the return value of ParseTime() without checking for a nil value.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants