[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Possible bug: 'git svn fetch' causes perl crash after update to 1.8.0

From: Pavel Borzenkov <pavel.borzenkov_at_gmail.com>
Date: Fri, 12 Jul 2013 19:39:13 +0400

On Thu, Jul 11, 2013 at 8:54 PM, Pavel Borzenkov
<pavel.borzenkov_at_gmail.com> wrote:
> On Thu, Jul 11, 2013 at 8:35 PM, Stefan Sperling <stsp_at_elego.de> wrote:
>> On Thu, Jul 11, 2013 at 07:47:19PM +0400, Pavel Borzenkov wrote:
>>> Hi,
>>>
>>> after update to svn 1.8.0 I have 100% reproducible perl crash during
>>> 'git svn fetch' with the following error (full backtrace + link to
>>> core at the end of the message):
>>>
>>> *** Error in `/usr/bin/perl': double free or corruption (!prev):
>>> 0x000000000332fc90 ***
>>>
>>> Downgrading to 1.7.10 helps.
>>> Any advice on what could be the reason?
>>
>> From the backtrace you provided, it looks like a pool cleanup handler
>> is trying to free memory that is already freed, or is trying to free
>> an invalid pointer. It's hard to say where the problem originates
>> since at the time the pool cleanup handler runs the error has already
>> happened elsewhere. Off-hand, I don't know what could be going wrong.
>>
>> This could well be a bug in Subversion 1.8. Or it could be a bug
>> in the perl script (because, yes, perl scripts need to manage
>> memory when using the swig bindings -- the bindings are a straight
>> wrapper around the C API and do not abstract memory management
>> away from the scripting language).
>>
>> Can you run this script in Valgrind or a similar analysis tool?
>
> Sure. Will do in a couple of days.

Ok, I tried to run it under valgrind. Unfortunately, it hangs.
It's still running (and has been running for several hours already),
but I doubt it'll ever finish. The following process consumes 100% of the CPU:
memcheck-amd64- valgrind --log-file=/tmp/git-svn/valgrind.log.%p
--trace-children=yes --error-limit=no --tool=memcheck
/usr/lib/git-core/git-svn fetch

It did quite a lot of work though. There is 98 valgrind log files (1
for each process). Most of them
are for 'git config' and all look Ok.

Currently, there are 4 git related processes running:
pbor 29850 0.0 0.5 106012 41020 pts/1 S+ 18:35 0:00
valgrind --log-file=/tmp/git-svn/valgrind.log.%p --trace-children=yes
--error-limit=no --tool=memcheck git svn fetch
pbor 29851 97.5 2.1 348292 178288 pts/1 R+ 18:35 47:09
valgrind --log-file=/tmp/git-svn/valgrind.log.%p --trace-children=yes
--error-limit=no --tool=memcheck /usr/lib/git-core/git-svn fetch
pbor 31125 0.0 0.5 120120 45028 pts/1 S+ 18:36 0:00
valgrind --log-file=/tmp/git-svn/valgrind.log.%p --trace-children=yes
--error-limit=no --tool=memcheck /usr/lib/git-core/git cat-file
--batch
pbor 31127 0.0 0.5 142924 44836 pts/1 S+ 18:36 0:00
valgrind --log-file=/tmp/git-svn/valgrind.log.%p --trace-children=yes
--error-limit=no --tool=memcheck /usr/lib/git-core/git hash-object -w
--stdin-paths --no-filters

The only log that contains valgrind reported errors is for
'/usr/lib/git-core/git-svn fetch'.
It's very long to post it here, so here is the link to ftp:
ftp://voidptr.ru/pub/valgrind.log.29851 (3.9M)

It definitely caught free() related errors, but not sure about other
possible memory corruptions.

>
>> That might help shed more light on the issue.
Received on 2013-07-12 17:40:15 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.