Bug: "git-svn fetch" segfaults on unknown user

Hi,

I noticed the following bug in git-svn version 1.6.0.3 (svn 1.5.5):

"git-svn fetch" segfaults if I provide an incomplete svn.authorsfile config
file setting with account<-->email mappings. This happens if an unknown user
account is found in the Subversion log.

If I do not provide svn.authorsfile at all, it doesn't crash.

Jens

2008/11/6 Jens Seidel [off-list ref]:

Hi,

I noticed the following bug in git-svn version 1.6.0.3 (svn 1.5.5):

"git-svn fetch" segfaults if I provide an incomplete svn.authorsfile config
file setting with account<-->email mappings. This happens if an unknown user
account is found in the Subversion log.

If I do not provide svn.authorsfile at all, it doesn't crash.

Are you sure this isn't the regular svn 1.5.x crash? Ie, does
compiling subversion with --disable-runtime-module-search fix it?

-- 
Mikael Magnusson

On Thu, Nov 06, 2008 at 03:43:18PM +0100, Mikael Magnusson wrote:

2008/11/6 Jens Seidel [off-list ref]:

quoted

I noticed the following bug in git-svn version 1.6.0.3 (svn 1.5.5):

"git-svn fetch" segfaults if I provide an incomplete svn.authorsfile config
file setting with account<-->email mappings. This happens if an unknown user
account is found in the Subversion log.

I should really provide more information:

I imported my Subversion repository in the past succesfully from my server
(svn+ssh protocol). Since I'm new to git (and still confused by the large
amount of git tools) I decided to start on a svnsync'ed copy of my repository
(file protocol) to avoid any harm. I added also some new config settings
including svn.authorsfile and fetching revisions started to fail.  The last
output was:

r38 = 4dca32e3d82a32206fd11545d4f270e118f51f12 (trunk@166)
        M       myproject/file

Revision 39 contained the unknown user account so I suspected the error
is related to an incomplete authors file.

I used following versions of Subversion:
Client: 1.5.5
Server: 1.5.3

After adding the missing account to the authors file it fetched all revisions,
called the garbage collector and stilled crashed with a core dump. Last
output:

Checked out HEAD:
  file:///home/jens/Subversion-Repository.synced/myproject/trunk r1700
Abgebrochen (core dumped)

This happened also after I removed the svn.authorsfile config setting.
My current settings:

[user]
  name = Jens Seidel
  email = jensseidel@users.sf.net
[color]
  diff = auto
  branch = auto
  interactive = auto
[svn]
  findcopiesharder = true
  rmdir = true

"gdb -c core" is useless, it just mentions the error occured in
"perl git-svn fetch" and there is no stacktrace (don't know how to
debug perl).

I removed now both [svn] options and it failed again. So it seems a problem
with file:// access while svn+ssh:// works well.

Are you sure this isn't the regular svn 1.5.x crash? Ie, does
compiling subversion with --disable-runtime-module-search fix it?

Huch? I follow the Subversion developer list and I'm not not aware of
such a problem. Will try it now ...

PS: Compared to previous releases of git the import is at least 10 times
faster. Good job!

Jens

On Thu, Nov 06, 2008 at 04:48:09PM +0100, Jens Seidel wrote:

On Thu, Nov 06, 2008 at 03:43:18PM +0100, Mikael Magnusson wrote:

quoted

2008/11/6 Jens Seidel [off-list ref]:

quoted

I noticed the following bug in git-svn version 1.6.0.3 (svn 1.5.5):

"git-svn fetch" segfaults

"gdb -c core" is useless, it just mentions the error occured in
"perl git-svn fetch" and there is no stacktrace (don't know how to
debug perl).

I removed now both [svn] options and it failed again. So it seems a problem
with file:// access while svn+ssh:// works well.

Could this be possible?

I tried now also to svnsync the same repository on the server which I access with
svn+ssh://. "svn-git fetch" fails on this as well, strange ...  The hook scripts
or the property added by "svnsync init" are not responsible, right?

quoted

Are you sure this isn't the regular svn 1.5.x crash? Ie, does
compiling subversion with --disable-runtime-module-search fix it?

No, it did not help.

I tried to reproduce it with a simple svn repository instead of my larger (not
public) one but failed.

What further information do you need? Is there any way to obtain more debug info?

Jens