Opened 11 years ago

Closed 10 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

Cc Me!

comment:2 Changed 11 years ago by jeff.science@…

Cc: jeff.science@… added

Cc Me!

comment:3 Changed 11 years ago by larryv (Lawrence Velázquez)

Cc: larryv@… added

Cc Me!

comment:4 Changed 11 years ago by nonstop.server@…

Cc: nonstop.server@… added

Cc Me!

comment:5 Changed 11 years ago by dm@…

Cc: dm@… added

Cc Me!

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!

Last edited 11 years ago by poemcode@… (previous) (diff)

comment:8 in reply to:  description 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:11 Changed 11 years ago by russt@…

Cc: russt@… added

Cc Me!

comment:12 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 in reply to:  12 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 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 in reply to:  14 ; 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:17 Changed 11 years ago by astricker@…

Cc: astricker@… added

Cc Me!

comment:18 Changed 11 years ago by jimjag (Jim Jagielski)

Cc: jimjag@… added

Cc Me!

comment:19 Changed 11 years ago by roland@…

Cc: roland@… added

Cc Me!

comment:20 Changed 10 years ago by hahn.seb@…

Cc: hahn.seb@… added

Cc Me!

comment:21 Changed 10 years ago by m214089

Cc: luis.kornblueh@… added

Cc Me!

comment:22 in reply to:  15 ; Changed 10 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 10 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 in reply to:  22 Changed 10 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 10 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 10 years ago by skymoo (Adam Mercer)

Just committed without an issue, looks like this issue is now fixed! Thanks.

comment:27 Changed 10 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 10 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 10 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 Changed 10 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 10 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 in reply to:  30 Changed 10 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 10 years ago by ci42

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.