subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Corveleyn <jcor...@gmail.com>
Subject Re: Failing svnrdump_tests.py#43 with 1.7.x on Windows (was: Re: 1.7.3 next week-ish?)
Date Fri, 10 Feb 2012 00:02:25 GMT
On Thu, Feb 9, 2012 at 9:55 PM, Greg Stein <gstein@gmail.com> wrote:
>
> On Feb 9, 2012 3:07 PM, "Paul Burba" <ptburba@gmail.com> wrote:
>>
>> On Thu, Feb 9, 2012 at 2:50 PM, Johan Corveleyn <jcorvel@gmail.com> wrote:
>> > On Thu, Feb 9, 2012 at 7:59 PM, Greg Stein <gstein@gmail.com> wrote:
>> >>
>> >> On Feb 9, 2012 1:23 PM, "Paul Burba" <ptburba@gmail.com> wrote:
>> >>>
>> >>> On Thu, Feb 9, 2012 at 11:49 AM, Daniel Shahaf <danielsh@elego.de>
>> >>> wrote:
>> >>> >...
>> >>
>> >>> > It is suggested there that setting
>> >>> > libsvn_ra_serf/update.c:MAX_NR_OF_CONNS
>> >>> > to "2" will prevent ra_serf from driving multiple window handlers
>> >>> > concurrently and thus avoid the bug.  (Presumably by causing the
>> >>> > file to
>> >>> > finish on the right side of the errant close_directory() call.)
>> >>>
>> >>> I just tried MAX_NR_OF_CONNS=2 with
>> >>> ^/subversion/branches/1.7.x@1242422 and the test still fails:
>> >>
>> >> Woah. Weird. I may have been mistaken. Please try 1.
>> >>
>> >> If that fails, then more investigation is needed.
>> >
>> > I just tried with MAX_NR_OF_CONNS=1 and it still fails.
>>
>> Same for me.
>
> Thanks, guys. It seems there is something wrong, probably independent of
> ordering issues.

I'm finally starting to get somewhere:

(all the below is with a trunk client with MAX_NR_OF_CONNS=1, vs. the
affected mod_dav_svn)

When processing 'psi', update_editor.c#handle_fetch exits early. It
skips the last block of 'if (APR_STATUS_IS_EOF(status))' (containing
the 'close_file' call), because status==730035. That seems to be
WSAEWOULDBLOCK (WinError.h): "A non-blocking socket operation could
not be completed immediately."

After that, for some reason, the close_directory is driven first, and
only later handle_fetch is run again to finish off psi.

That might explain the Windows-ness a bit (specific socket behavior),
combined with some randomness (sometimes it does "complete
immediately", sometimes it doesn't). It still doesn't explain the
relatedness to 1.7.x.

Open questions:

- What's the link with Philip's change in liveprops.c ('if (kind !=
svn_node_file) return DAV_PROP_INSERT_NOTSUPP;') ?

- Why the WSAEWOULDBLOCK error? Maybe that's expected and normal, and
shouldn't cause a problem in and of itself?

- Why, after exiting handle_fetch early, does ra_serf first do the
close_directory first? I don't know much about how ra_serf organizes
these things.
(actually, the WSAEWOULDBLOCK error also happens earlier during the
update-drive, when adding trunk/D/G/rho, but it doesn't cause a
problem -- no close_directory interference, just a clean "rerun" of
handle_fetch).

-- 
Johan

Mime
View raw message