search

libgit2 / git2go

Git to Go; bindings for libgit2. Like McDonald's but tastier.
MIT License
1.92k stars 316 forks source link

Random `invalid pointer handle` using Managed Transport #915

Open pjbgf opened 2 years ago

pjbgf commented 2 years ago

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?

pjbgf commented 2 years ago

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.