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

RE: Infinite loop on when using svn blame

From: Joel Low <joel_at_joelsplace.sg>
Date: Mon, 24 Oct 2011 20:35:26 +0800

Hi Bert,

> -----Original Message-----
> From: Bert Huijben [mailto:bert_at_qqmail.nl]
> Sent: Monday, 24 October, 2011 8:22 PM
> To: Joel Low; 'Subversion Developers' List'
> Cc: Mark Phippard
> Subject: RE: Infinite loop on when using svn blame
>
> > -----Original Message-----
> > From: Joel Low [mailto:joel_at_joelsplace.sg]
> > Sent: zondag 23 oktober 2011 10:15
> > To: Subversion Developers' List (dev_at_subversion.apache.org)
> > Subject: RE: Infinite loop on when using svn blame
> >
> > > -----Original Message-----
> > > From: Joel Low [mailto:joel_at_joelsplace.sg]
> > > Sent: Sunday, 23 October, 2011 4:05 PM
> > > To: Subversion Developers' List (dev_at_subversion.apache.org)
> > > Subject: Infinite loop on when using svn blame
> > >
> > > Hello List,
> > >
> > > I've got an infinite loop when running svn blame over file:/// on
> my
> > > own SVN binaries (Windows, x64, VS 2008)
> > >
> > > I'm not sure if it is caused by my repository (it's public -- the
> > > Eraser SourceForge repository, repository can be rsynced from
> > > SourceForge servers) Trying to run blame from TortoiseSVN seems to
> work
> > > fine, so I did some debugging.
> > >
> > > It seems that there's an infinite loop in find_identical_prefix
> > > (diff_file.c:379, svn 1.7.1 tag), specifically within the ifdefs in
> > > SVN_UNALIGNED_ACCESS_IS_OK between lines 417 and 455. I disabled
> > the
> > > whole block since the comment in svn_types.h details that
> > > SVN_UNALIGNED_ACCESS_IS_OK is an optimisation opportunity define
> > and
> > > rebuilt; the blame runs successfully then.
> >
> > Sorry for the noise. The definition of apr_uintptr_t is important:
> WIN32
> is
> > defined in the MSVC project files, but APR detects x64 purely by
> defines
> (in
> > this case WIN64) which the project files do not define. Defining
> WIN64
> (and
> > WIN32) in all projects seems to have fixed the problem.
>
> Which apr version did you use?
>
> Apr 1.3.X checks for WIN64, but 1.4.X checks for _WIN64 and WIN64.

I built against Apr 1.4.5 and Apr-util 1.3.12.

>
> I think we don't define WIN64 in our build, but _WIN64 is automatically
> added by the Microsoft C++ compiler for x64 builds.
>
> Bert

Yes, the generated project files only define WIN32. In my build of APR, apr.h defines:

#ifdef WIN64
#define APR_SIZEOF_VOIDP 8
#else
#define APR_SIZEOF_VOIDP 4
#endif

A quick search around the APR source tree (I loaded up the Apache HTTPd solution, of which libapr and libapr-util are projects in) revealed no references to _WIN64.
Received on 2011-10-24 14:36:12 CEST

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

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