`git svn dcommit` segfault

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,

I've been using git-svn on this repository for a while now, and all has
been well. However, this time it segfaulted in the middle of a dcommit
(4 commits into about 15). I've had to sanitise the file names, as this
is a commercial project.

$ git svn dcommit
...
        M       <snip_file>
Committed r164
        M       <snip_file>
r164 = 72ff1bf62f9b3828efb93d1b2681d154e960b8a2 (git-svn)
No changes between current HEAD and refs/remotes/git-svn
Resetting to the latest refs/remotes/git-svn
<snip_file>: needs update
<snip_file>: needs update
<snip_file>: needs update
<snip_file>: needs update
<snip_file>: needs update
<snip_file>: needs update
<snip_file>: needs update
<snip_file>: needs update
<snip_file>: needs update
<snip_file>: needs update
<snip_file>: needs update
<snip_file>: needs update
<snip_file>: needs update
Segmentation fault

It was git-svn that segfaulted I assume, not any git commands it calls,
because I see this in my syslog:
git-svn[27348]: segfault at 18 rip 2b9bc87e17e3 rsp 7fffe6ed04f0 error 4


And now I have a dirty checkout:
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
#       modified:   <snip_file>
#       modified:   <snip_file>
#       modified:   <snip_file>
#       modified:   <snip_file>
#       modified:   <snip_file>
#       modified:   <snip_file>
#       modified:   <snip_file>
#       modified:   <snip_file>
#       modified:   <snip_file>
#       modified:   <snip_file>
#       modified:   <snip_file>
#       modified:   <snip_file>
#       modified:   <snip_file>
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#           <snip_file>
#           <snip_file>
#           <snip_file>
#           <snip_file>
#           <snip_file>
#           <snip_file>
#           <snip_file>
no changes added to commit (use "git add" and/or "git commit -a")

It *looks* as if this dirty state is the sum total of the outstanding
commits, so I don't think I've lost my work, only my history of that
work.


`git log` shows up to r164, the last one before the segfault.


I can't run dcommit again, because my checkout is now dirty:
$ git svn dcommit
Cannot dcommit with a dirty index.  Commit your changes first, or stash
them with `git stash'.


fsck shows some dangling entries:
$ git fsck
dangling blob 6d806e5c5dc0bfcbae3511a37695e58ae0e0c527
dangling tree d8603f524dbb9d2c4a76fe5b2c147c1140daf808
dangling tree 93027419e21371bb94e488ab6dec085147622ffa
dangling blob 0155d5f782e77a77a70b2fd7835cd84bd0bfb829
dangling tree 05164a3f07b46d0e2cf700688e3484229beb31b4
dangling blob 0db60b87c33d0cdfdabfd24028dbb1185caabc4f
dangling tree 74560de127259a16519dc69b10aace3e167c0150
dangling blob 23e81c44b8325f976146072f061b97c015006d3b
dangling tree f72af1a9c583c560b17668a0417a8d653a5110df
dangling blob 44cc9844484fd072f98d4ac0f6e395a57c5d9277


I'd re-run it to get a core file, but I don't know how to get myself
back into the initial state.

I'm using 'git version 1.5.4.3', and 'svn, version 1.4.6 (r28521)' on
the client. The server is 'svn, version 1.3.1 (r19032)', I think.

I'm a bit stuck! Any help is much appreciated. Would any other
information be useful?

Thanks
Tim

-- 
Tim Stoakes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux