~emersion/hut#21: 
SIGSEGV in "builds list" with invalid access token

When the config file contains an invalid access token (e.g. a garbage value like "invalid_token"), running hut builds list results in a SIGSEGV.

System: macOS 12.3.1

Go version: go version go1.18.1 darwin/arm64

Config file:

instance "sr.ht" {
	access-token "something_fake"
}

Reproduce:

hut builds list

Stack trace:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x2 addr=0x0 pc=0x100bb9d04]

goroutine 1 [running]:
main.newBuildsListCommand.func1(0x14000186000?, {0x1400014a740?, 0x2?, 0x2?})
	/Users/greg/src/hut/builds.go:318 +0x94
github.com/spf13/cobra.(*Command).execute(0x14000186000, {0x1400014a700, 0x2, 0x2})
	/Users/greg/.go/pkg/mod/github.com/spf13/cobra@v1.4.0/command.go:860 +0x4ac
github.com/spf13/cobra.(*Command).ExecuteC(0x14000154f00)
	/Users/greg/.go/pkg/mod/github.com/spf13/cobra@v1.4.0/command.go:974 +0x354
github.com/spf13/cobra.(*Command).Execute(...)
	/Users/greg/.go/pkg/mod/github.com/spf13/cobra@v1.4.0/command.go:902
github.com/spf13/cobra.(*Command).ExecuteContext(...)
	/Users/greg/.go/pkg/mod/github.com/spf13/cobra@v1.4.0/command.go:895
main.main()
	/Users/greg/src/hut/main.go:49 +0x29c

I ran it in Delve and pinpointed it to this line in builds.go:

for _, job := range jobs.Results {
	printJob(&job)
}

Printing jobs in Delve shows:

(dlv) p jobs
*git.sr.ht/~emersion/hut/srht/buildssrht.JobCursor {
	Results: []git.sr.ht/~emersion/hut/srht/buildssrht.Job len: 0, cap: 0, [],
	Cursor: *(unreadable invalid length: -486054628144709631),}

It looks to me like the cursor is invalid, but I could be misunderstanding what it's supposed to look like.

Notably, this does not happen with other commands such as hut todo list or hut lists list.

Status
RESOLVED FIXED
Submitter
~gpanders
Assigned to
Submitted
7 months ago
Updated
7 months ago
Labels
bug

~xenrox 7 months ago

Thanks for your report!

This is caused by an out-of-date core-go dependency of builds.sr.ht. I have submitted a patch to fix this and will further add a nil check in hut.

~xenrox REPORTED FIXED 6 months ago

This bug is fixed with this commit. We actually don't need an additional nil check since the query only uses non-nullable fields.

Register here or Log in to comment, or comment via email.