fatal error: unexpected signal during runtime execution in Clone(...) #928

New Issue

2022-08-29T14:32:12-05:00

patrickdevivo commented

2022-08-29 14:32:12 -05:00

(Migrated from github.com)

Hi there! We're seeing a pretty consistent crash in our code that appears to be originating in the Clone call in libgit2 (via git2go). We're using github.com/libgit2/git2go/v33 v33.0.9 and are seeing the following:

fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xf8de5c]

runtime stack:
runtime.throw({0x133c30a?, 0xeddcf4?})
 /usr/local/go/src/runtime/panic.go:992 +0x71
runtime.sigpanic()
 /usr/local/go/src/runtime/signal_unix.go:802 +0x389

goroutine 15 [syscall, locked to thread]:
runtime.cgocall(0xec7c20, 0xc001027960)
 /usr/local/go/src/runtime/cgocall.go:157 +0x5c fp=0xc001027938 sp=0xc001027900 pc=0x4348bc
github.com/libgit2/git2go/v33._Cfunc_git_clone(0xc001856e78, 0x7fe8fc0042d0, 0x7fe8fc004300, 0xc000fbc340)
 _cgo_gotypes.go:3233 +0x4c fp=0xc001027960 sp=0xc001027938 pc=0xaae34c
github.com/libgit2/git2go/v33.Clone.func3(0xc000fbc340?, 0xc001124360?, 0xc001728280?, 0xc001027a50?)
 /go/pkg/mod/github.com/libgit2/git2go/v33@v33.0.9/clone.go:43 +0x91 fp=0xc0010279b8 sp=0xc001027960 pc=0xac6d91
github.com/libgit2/git2go/v33.Clone({0xc0014043f0?, 0x0?}, {0xc001cb2fc0, 0x1e}, 0xc001124360)
 /go/pkg/mod/github.com/libgit2/git2go/v33@v33.0.9/clone.go:43 +0x19e fp=0xc001027a60 sp=0xc0010279b8 pc=0xac6ade
...

This is where we're calling out to the Clone in our code: b1165024f3/internal/syncer/git_files.go (L81)

We would really appreciate any points anyone may have here - we're trying to understand where the issue is and if it's in our use of the library or elsewhere.

Thanks!

Hi there! We're seeing a pretty consistent crash in our code that appears to be originating in the `Clone` call in libgit2 (via `git2go`). We're using `github.com/libgit2/git2go/v33 v33.0.9` and are seeing the following: ``` fatal error: unexpected signal during runtime execution [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xf8de5c] runtime stack: runtime.throw({0x133c30a?, 0xeddcf4?}) /usr/local/go/src/runtime/panic.go:992 +0x71 runtime.sigpanic() /usr/local/go/src/runtime/signal_unix.go:802 +0x389 goroutine 15 [syscall, locked to thread]: runtime.cgocall(0xec7c20, 0xc001027960) /usr/local/go/src/runtime/cgocall.go:157 +0x5c fp=0xc001027938 sp=0xc001027900 pc=0x4348bc github.com/libgit2/git2go/v33._Cfunc_git_clone(0xc001856e78, 0x7fe8fc0042d0, 0x7fe8fc004300, 0xc000fbc340) _cgo_gotypes.go:3233 +0x4c fp=0xc001027960 sp=0xc001027938 pc=0xaae34c github.com/libgit2/git2go/v33.Clone.func3(0xc000fbc340?, 0xc001124360?, 0xc001728280?, 0xc001027a50?) /go/pkg/mod/github.com/libgit2/git2go/v33@v33.0.9/clone.go:43 +0x91 fp=0xc0010279b8 sp=0xc001027960 pc=0xac6d91 github.com/libgit2/git2go/v33.Clone({0xc0014043f0?, 0x0?}, {0xc001cb2fc0, 0x1e}, 0xc001124360) /go/pkg/mod/github.com/libgit2/git2go/v33@v33.0.9/clone.go:43 +0x19e fp=0xc001027a60 sp=0xc0010279b8 pc=0xac6ade ... ``` This is where we're calling out to the `Clone` in our code: https://github.com/mergestat/fuse/blob/b1165024f3dc65fd498bad3b1f1c8e3b54f73f8e/internal/syncer/git_files.go#L81 We would really appreciate any points anyone may have here - we're trying to understand where the issue is and if it's in our use of the library or elsewhere. Thanks!

pjbgf commented

2022-10-05 09:00:40 -05:00

(Migrated from github.com)

@patrickdevivo are you getting this every time you execute or only during long executions? We have experienced a similar issue, which transformed into a new error when we started doing a remote-ls before the clone operation.

For us they tend to happen only after a few hours of executing clone operations, but we are still investigating the root causes.

@patrickdevivo are you getting this every time you execute or only during long executions? We have experienced a similar issue, which [transformed into a new error](https://github.com/fluxcd/image-automation-controller/issues/415) when we started doing a remote-ls before the clone operation. For us they tend to happen only after a few hours of executing clone operations, but we are still investigating the root causes.

Sign in to join this conversation.