Random invalid pointer handle using Managed Transport #915

New Issue

2022-05-08T11:32:25-05:00

pjbgf commented

2022-05-08 11:32:25 -05:00

(Migrated from github.com)

We have implemented a managed transport for git2go in fluxcd/source-controller, which is heavily based on git2go's default implementation and it works quite well most of times.

However, we have noticed that at times git2go may panic when trying to call git2go/v33.(*HandleList).Get.
I am finding it difficult to reproduce this consistently, but have experienced it a few times (e.g. the Git Fetch example below) on my local setup.

Git Fetch

panic: invalid pointer handle: 0x7f8098019b20

goroutine 367 [running]:
github.com/libgit2/git2go/v33.(*HandleList).Get(0x0?, 0x7f8098019b20)
        /home/levi/go/pkg/mod/github.com/libgit2/git2go/v33@v33.0.9/handles.go:64 +0x12e
github.com/libgit2/git2go/v33.certificateCheckCallback(0xf76656?, 0x7f809803c0e8, 0x1, 0xc0000ec1a0?, 0x300000002?)
        /home/levi/go/pkg/mod/github.com/libgit2/git2go/v33@v33.0.9/remote.go:445 +0x3d
github.com/libgit2/git2go/v33._Cfunc_git_remote_fetch(0x7f8098007f40, 0xc000742030, 0xc0009cf110, 0x0)
        _cgo_gotypes.go:7125 +0x4c
github.com/libgit2/git2go/v33.(*Remote).Fetch.func2(0xc0009cf110?, 0xc000117cb0?, 0x33d3e30?, 0x90?)
        /home/levi/go/pkg/mod/github.com/libgit2/git2go/v33@v33.0.9/remote.go:1044 +0xa7
github.com/libgit2/git2go/v33.(*Remote).Fetch(0xc0005f6000, {0xc000f71360, 0x1, 0x1}, 0x2?, {0x0?, 0x0})
        /home/levi/go/pkg/mod/github.com/libgit2/git2go/v33@v33.0.9/remote.go:1044 +0x1f2

Other users are experiencing it quite consistently but during a clone, at the point of getting to the credentials call back:

Getting smart credentials during Clone

panic: invalid pointer handle: 0x7ff5fdce8500

goroutine 361 [running]:
github.com/libgit2/git2go/v33.(*HandleList).Get(0xc000480d00, 0x7ff5fdce8500)
github.com/libgit2/git2go/v33@v33.0.9/handles.go:64 +0x12e
github.com/libgit2/git2go/v33.credentialsCallback(0xc00010f000, 0xc0003e52b0, 0xc0008dc640, 0xc000d32500, 0x260, 0xc00007e8d0)
github.com/libgit2/git2go/v33@v33.0.9/remote.go:373 +0x45
github.com/libgit2/git2go/v33._Cfunc_git_transport_smart_credentials(0xc0003e52b0, 0x7ff5fdd6f490, 0x0, 0x40)
_cgo_gotypes.go:8811 +0x4c
github.com/libgit2/git2go/v33.(*Transport).SmartCredentials.func2(0xc0003e52b0, 0xc0003e52b0, 0x1af7300, 0x40)
github.com/libgit2/git2go/v33@v33.0.9/transport.go:112 +0x90
github.com/libgit2/git2go/v33.(*Transport).SmartCredentials(0x1dc50fd, {0x0, 0xc000278990}, 0x1)
github.com/libgit2/git2go/v33@v33.0.9/transport.go:112 +0xeb
github.com/fluxcd/source-controller/pkg/git/libgit2/managed.(*sshSmartSubtransport).Action(0xc000382000, {0xc000efd290, 0x29}, 0x2)
github.com/fluxcd/source-controller@v0.24.0/pkg/git/libgit2/managed/ssh.go:174 +0x32e
github.com/libgit2/git2go/v33.smartSubtransportActionCallback(0x4e31e7, 0x7ff5fd87e978, 0x1000c00199a600, 0x1, 0x2)
github.com/libgit2/git2go/v33@v33.0.9/transport.go:374 +0xb0
github.com/libgit2/git2go/v33._Cfunc_git_remote_free(0x7ff5fdf7ffe0)
_cgo_gotypes.go:7146 +0x45
github.com/libgit2/git2go/v33.(*Remote).free.func1(0x1cf9060)
github.com/libgit2/git2go/v33@v33.0.9/remote.go:603 +0x46
github.com/libgit2/git2go/v33.(*Remote).free(0xc0002be0c0)
github.com/libgit2/git2go/v33@v33.0.9/remote.go:603 +0x36
github.com/libgit2/git2go/v33.(*Remote).Free(0xc0002be0c0)
github.com/libgit2/git2go/v33@v33.0.9/remote.go:614 +0x48

The handle's list is part of git2go internal state, so I am not quite sure how we can ensure it is already properly set.
Has anyone else experienced this? Any pointers on how to resolve it?

We have implemented a managed transport for `git2go` in [fluxcd/source-controller](https://github.com/fluxcd/source-controller/tree/main/pkg/git/libgit2/managed), which is heavily based on git2go's default implementation and it works quite well most of times. However, we have noticed that at times `git2go` may `panic` when trying to call `git2go/v33.(*HandleList).Get`. I am finding it difficult to reproduce this consistently, but have experienced it a few times (e.g. the Git Fetch example below) on my local setup. **Git Fetch** ``` panic: invalid pointer handle: 0x7f8098019b20 goroutine 367 [running]: github.com/libgit2/git2go/v33.(*HandleList).Get(0x0?, 0x7f8098019b20) /home/levi/go/pkg/mod/github.com/libgit2/git2go/v33@v33.0.9/handles.go:64 +0x12e github.com/libgit2/git2go/v33.certificateCheckCallback(0xf76656?, 0x7f809803c0e8, 0x1, 0xc0000ec1a0?, 0x300000002?) /home/levi/go/pkg/mod/github.com/libgit2/git2go/v33@v33.0.9/remote.go:445 +0x3d github.com/libgit2/git2go/v33._Cfunc_git_remote_fetch(0x7f8098007f40, 0xc000742030, 0xc0009cf110, 0x0) _cgo_gotypes.go:7125 +0x4c github.com/libgit2/git2go/v33.(*Remote).Fetch.func2(0xc0009cf110?, 0xc000117cb0?, 0x33d3e30?, 0x90?) /home/levi/go/pkg/mod/github.com/libgit2/git2go/v33@v33.0.9/remote.go:1044 +0xa7 github.com/libgit2/git2go/v33.(*Remote).Fetch(0xc0005f6000, {0xc000f71360, 0x1, 0x1}, 0x2?, {0x0?, 0x0}) /home/levi/go/pkg/mod/github.com/libgit2/git2go/v33@v33.0.9/remote.go:1044 +0x1f2 ``` Other users are experiencing it quite consistently but during a clone, at the point of getting to the credentials call back: **Getting smart credentials during Clone** ``` panic: invalid pointer handle: 0x7ff5fdce8500 goroutine 361 [running]: github.com/libgit2/git2go/v33.(*HandleList).Get(0xc000480d00, 0x7ff5fdce8500) github.com/libgit2/git2go/v33@v33.0.9/handles.go:64 +0x12e github.com/libgit2/git2go/v33.credentialsCallback(0xc00010f000, 0xc0003e52b0, 0xc0008dc640, 0xc000d32500, 0x260, 0xc00007e8d0) github.com/libgit2/git2go/v33@v33.0.9/remote.go:373 +0x45 github.com/libgit2/git2go/v33._Cfunc_git_transport_smart_credentials(0xc0003e52b0, 0x7ff5fdd6f490, 0x0, 0x40) _cgo_gotypes.go:8811 +0x4c github.com/libgit2/git2go/v33.(*Transport).SmartCredentials.func2(0xc0003e52b0, 0xc0003e52b0, 0x1af7300, 0x40) github.com/libgit2/git2go/v33@v33.0.9/transport.go:112 +0x90 github.com/libgit2/git2go/v33.(*Transport).SmartCredentials(0x1dc50fd, {0x0, 0xc000278990}, 0x1) github.com/libgit2/git2go/v33@v33.0.9/transport.go:112 +0xeb github.com/fluxcd/source-controller/pkg/git/libgit2/managed.(*sshSmartSubtransport).Action(0xc000382000, {0xc000efd290, 0x29}, 0x2) github.com/fluxcd/source-controller@v0.24.0/pkg/git/libgit2/managed/ssh.go:174 +0x32e github.com/libgit2/git2go/v33.smartSubtransportActionCallback(0x4e31e7, 0x7ff5fd87e978, 0x1000c00199a600, 0x1, 0x2) github.com/libgit2/git2go/v33@v33.0.9/transport.go:374 +0xb0 github.com/libgit2/git2go/v33._Cfunc_git_remote_free(0x7ff5fdf7ffe0) _cgo_gotypes.go:7146 +0x45 github.com/libgit2/git2go/v33.(*Remote).free.func1(0x1cf9060) github.com/libgit2/git2go/v33@v33.0.9/remote.go:603 +0x46 github.com/libgit2/git2go/v33.(*Remote).free(0xc0002be0c0) github.com/libgit2/git2go/v33@v33.0.9/remote.go:603 +0x36 github.com/libgit2/git2go/v33.(*Remote).Free(0xc0002be0c0) github.com/libgit2/git2go/v33@v33.0.9/remote.go:614 +0x48 ``` The handle's list is part of `git2go` internal state, so I am not quite sure how we can ensure it is already properly set. Has anyone else experienced this? Any pointers on how to resolve it?

pjbgf commented

2022-07-12 10:10:42 -05:00

(Migrated from github.com)

Unfortunately, the only way we found to consistently avoid this issue was to not use transport.SmartCredentials() and stop relying on git2go primitives to store and return data we may later need during the callbacks.

Unfortunately, the only way we found to consistently avoid this issue was to not use `transport.SmartCredentials()` and stop relying on git2go primitives to store and return data we may later need during the callbacks.

Sign in to join this conversation.