tree-walk causes sigsegv #513
Labels
No Label
bug
duplicate
enhancement
invalid
question
up for grabs
wontfix
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: jcarr/git2go#513
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
the following go code can cause error:
after some output, the error stack is as follow:
it always fail on _Cfunc_git_tree_entry_name, however the round count can vary.
i'm using libgit2 v0.27.8 and git2go.v27
the test repository contains more than 4000 files, don't know whether it matters
I am also encountering this same problem:
I can systematically reproduce this with
9a1a9189b6
The pointer
_entry
thatCallbackGitTreeWalk
gets already has a very unusual value for the one that causes the crash:0x6176616a2e72674c
, whereas all previous entries are around0x7fd7d8009de0
and all start with0x7fd7d8009...
.I will try to see if this error can be reproduced with libgit2 only, excluding the Go wrapper.
thanks for your update😊
The following C libgit2 client code walks the same repository also in pre-order but does not segfault. I guess this means that the issue is most likely within git2go itself.
Here is the Go equivalent of the same C code:
Depending on the invalid memory address, it crashes with either:
object hash mismatch - expected 0000000000000000000000000000000000000000 but got 5cc7508cd3b4b5419bdf80cdf231408d16309d09
FYI, adding
runtime.KeepAlive(tree)
after theWalk()
call seems to resolve the issue:I'll have a deeper look to better understand why and if successful open a PR for this issue.
The fix is probably as easy as replacing:
with:
Otherwise a copy of the
Tree
gets kept alive, but my outer one gets finalized and so the underlying C pointer (which both copies share) gets freed. I'll test this tomorrow before opening the PR.I am no longer able to reproduce this issue with the change contained in the pull requests.