Opened 11 years ago
Closed 11 years ago
#39986 closed defect (fixed)
git-core +svn: errors when cloning new repo
Reported by: | skymoo (Adam Mercer) | Owned by: | ci42 |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.2.0 |
Keywords: | svn | Cc: | cooljeanius (Eric Gallager), jeff.science@…, larryv (Lawrence Velázquez), nonstop.server@…, dm@…, poemcode@…, russt@…, astricker@…, jimjag (Jim Jagielski), roland@…, hahn.seb@…, m214089 |
Port: | git-core |
Description
Since subversion was updated to version 1.8.x git-svn had not been working correctly, when trying to clone a new repo it fails with:
$ git svn clone -s -r90000:HEAD https://svn.macports.org/repository/macports/trunk/dports Initialized empty Git repository in /Users/ram/macports/dports/.git/ Using higher level of URL: https://svn.macports.org/repository/macports/trunk/dports => https://svn.macports.org/repository/macports perl5.12(6874) malloc: *** error for object 0x7fed70e2ae00: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug error: git-svn died of signal 6 $
Change History (33)
comment:1 Changed 11 years ago by cooljeanius (Eric Gallager)
Cc: | egall@… added |
---|
comment:6 Changed 11 years ago by poemcode@…
I meet the same problem. All the command such as "git svn ... " print: perl5.12(8747,0x7fff7cc17180) malloc: * error for object 0x7fa482d35e00: pointer being freed was not allocated
comment:7 Changed 11 years ago by poemcode@…
Cc: | poemcode@… added |
---|
Cc Me!
I meet the same problem. All the command such as "git svn ... " print: perl5.12(8747,0x7fff7cc17180) malloc: * error for object 0x7fa482d35e00: pointer being freed was not allocated
comment:8 Changed 11 years ago by jimjag (Jim Jagielski)
This is due to git-svn not being compatible with subversion 1.8.x yet (or the perl-bindings for it). I proposed creating a subversion1.7 port and making git-core +svn dependent on that. In the meantime, downgrading to svn 1.7 is required.
Replying to ram@…:
Since subversion was updated to version 1.8.x git-svn had not been working correctly, when trying to clone a new repo it fails with:
$ git svn clone -s -r90000:HEAD https://svn.macports.org/repository/macports/trunk/dports Initialized empty Git repository in /Users/ram/macports/dports/.git/ Using higher level of URL: https://svn.macports.org/repository/macports/trunk/dports => https://svn.macports.org/repository/macports perl5.12(6874) malloc: *** error for object 0x7fed70e2ae00: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug error: git-svn died of signal 6 $
comment:9 Changed 11 years ago by jeff.science@…
What's super-awesome about svn is that an repos that were upgraded to 1.8 no longer work with 1.7, so any of us that upgraded to svn 1.8 and necessarily upgraded a repo or two or 20 are going to have to checkout all of those repos from scratch in order to use the git-svn with svn 1.7.
I'm not saying this is all macports' fault, but I fault someone for not figuring out that this was broken before rolling it out. Of course, the major fail is by the svn developers that constantly break backwards compatibility of their repo format.
comment:10 Changed 11 years ago by philippe.lang@…
Same problem here
perl5.12(8593,0x7fff78559180) malloc: *** error for object 0x7f87cb541600: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug error: git-svn died of signal 6
comment:12 follow-up: 13 Changed 11 years ago by ci42
Does this problem still persists?
I'm not able to reproduce it. Cloning the MacPorts subversion repository (https://svn.macports.org/repository/macports) using git-svn works fine for me. The repo runs on subversion 1.6.11 (r934486
). Cloning the subversion repo (http://svn.apache.org/repos/asf/subversion) which runs on 1.8.1 (r1503906
) fails, but with a different error:
Temp file with moniker 'svn_delta' already in use at Git.pm line 1250
This error, and a second one also occuring when fetching from 1.8.x repos, is fixed in r109905.
comment:13 Changed 11 years ago by skymoo (Adam Mercer)
Replying to ciserlohn@…:
Does this problem still persists?
Yep:
[ram@cizin svn]$ port installed git-core subversion subversion-perlbindings-5.12 The following ports are currently installed: git-core @1.8.3.4_1+bash_completion+credential_osxkeychain+doc+pcre+python27+svn (active) subversion @1.7.10_1 subversion @1.8.1_3 (active) subversion-perlbindings-5.12 @1.7.10_0 subversion-perlbindings-5.12 @1.8.1_1 (active) [ram@cizin svn]$ git svn clone -s -r100000:HEAD https://svn.macports.org/repository/macports/trunk/dports Initialized empty Git repository in /Users/ram/svn/dports/.git/ Using higher level of URL: https://svn.macports.org/repository/macports/trunk/dports => https://svn.macports.org/repository/macports perl5.12(33718) malloc: *** error for object 0x7f806be31e00: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug error: git-svn died of signal 6 [ram@cizin svn]$
The only way to make git-svn
usable is to revert back to subversion
1.7.x.
comment:14 follow-up: 15 Changed 11 years ago by ci42
Ok,
the problem is not subversion per se, but the combination of subversion 1.8 and the -s option.
git svn clone -s -r100000:HEAD https://svn.macports.org/repository/macports/trunk/dports
fails as described. But
git svn clone -s -r100000:HEAD https://svn.macports.org/repository/macports
works. As well as
git svn clone -r100000:HEAD https://svn.macports.org/repository/macports/trunk/dports
comment:15 follow-up: 22 Changed 11 years ago by skymoo (Adam Mercer)
Replying to ciserlohn@…:
the problem is not subversion per se, but the combination of subversion 1.8 and the -s option.
Thanks, I can confirm that is the case. However updating a pre-existing repository, that was probably cloned using the -s option, results in an error after a while:
perl5.12(15733) malloc: *** error for object 0x7f9129d43600: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug error: git-svn died of signal 6
I'll reclone, without the -s option, and then see how that behaves.
comment:16 Changed 11 years ago by skymoo (Adam Mercer)
About 80% of the way through the reclone process, without the -s option, it failed with a similar error:
SVN connection failed somewhere... perl5.12(16456) malloc: *** error for object 0x7fd8b623aa00: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug error: git-svn died of signal 6
I'm going back to subversion-1.7.x
until this can be addressed.
comment:22 follow-up: 24 Changed 11 years ago by ci42
Replying to ram@…:
Replying to ciserlohn@…:
Thanks, I can confirm that is the case. However updating a pre-existing repository, that was probably cloned using the -s option, results in an error after a while:
Could you please update to git-core 1.8.4.1 (112427), test again and report the results. I successfully cloned several repositories and did local operations on them. But I don't have a pre-existing repository to test against and no opportunity yet to test the dcommit command.
comment:23 Changed 11 years ago by astricker@…
It looks good now. The git-svn repositories which previously failed with svn 1.8 are working now. Although this wasn't a thoroughly test yet.
I've tested with git version 1.8.4.1 and svn version 1.8.3 (r1516576)
comment:24 Changed 11 years ago by skymoo (Adam Mercer)
Replying to ciserlohn@…:
Could you please update to git-core 1.8.4.1 (112427), test again and report the results. I successfully cloned several repositories and did local operations on them. But I don't have a pre-existing repository to test against and no opportunity yet to test the dcommit command.
Just successfully pulled down about a weeks worth of changes from the MacPorts SVN using the following versions:
$ port installed git-core subversion subversion-perlbindings-5.12 The following ports are currently installed: git-core @1.8.4.1_0+bash_completion+credential_osxkeychain+doc+pcre+python27+svn (active) subversion @1.8.3_3 (active) subversion-perlbindings-5.12 @1.8.3_2 (active)
I don't have anything to commit yet either but I'll update this ticket when I do. So far so good.
comment:25 Changed 11 years ago by astricker@…
Now I've had the chance to test the svn commit too: It works.
The following ports are currently installed: git-core @1.8.4.1_0+bash_completion+credential_osxkeychain+doc+pcre+python27+svn (active) subversion @1.8.3_3 (active) subversion-perlbindings-5.12 @1.8.3_2 (active)
Thanks for fixing this issue.
comment:26 Changed 11 years ago by skymoo (Adam Mercer)
Just committed without an issue, looks like this issue is now fixed! Thanks.
comment:27 Changed 11 years ago by astricker@…
Well bad news. A recent commit with a few renames failed badly. I've had to revert to Subversion 1.7.x again to be able to commit. This was in an existing git-svn repo.
comment:28 Changed 11 years ago by astricker@…
It looks like there are some more fixes in the pipeline, from announce for Git 1.8.5-rc1:
Updates since v1.8.4 -------------------- Foreign interfaces, subsystems and ports. * "git-svn" used with SVN 1.8.0 when talking over https:// connection dumped core due to a bug in the serf library that SVN uses. Work it around on our side, even though the SVN side is being fixed. [...] * Subversion 1.8.0 that was recently released breaks older subversion clients coming over http/https in various ways. [...]
I don't know if this solves the problem, but I'll wait for Git 1.8.5
comment:29 Changed 11 years ago by astricker@…
It looks like this is not only a local problem on my machine. Other people experiencing the same problem with renames like this on on stackoverflow.
Finally the problem has hit the git mailing list.
comment:30 follow-up: 32 Changed 11 years ago by ci42
Git is now at version 1.8.5.2. I've not experienced any problems so far. Please update, test and report the results.
comment:31 Changed 11 years ago by astricker@…
As the initial problem this ticket was opened is solved I think we can close this ticket. The problem I reported last probably still exists in latest 1.8.5.2, but I can't reproduce it easily. I've reported the problem to upstream (git mailing list). A new checkout of a repository may fix the problem. But unfortunately in my private (and huge) repository I've had the problem even after a fresh checkout.
As this is an upstream bug, MacPorts cannot fix it, so this ticket can be closed.
comment:32 Changed 11 years ago by skymoo (Adam Mercer)
Replying to ciserlohn@…:
Git is now at version 1.8.5.2. I've not experienced any problems so far. Please update, test and report the results.
I haven't encountered the problem in a while.
comment:33 Changed 11 years ago by ci42
Resolution: | → fixed |
---|---|
Status: | new → closed |
Cc Me!