On Thu, Feb 9, 2012 at 9:55 PM, Greg Stein <gstein_at_gmail.com> wrote:
>
> On Feb 9, 2012 3:07 PM, "Paul Burba" <ptburba_at_gmail.com> wrote:
>>
>> On Thu, Feb 9, 2012 at 2:50 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>> > On Thu, Feb 9, 2012 at 7:59 PM, Greg Stein <gstein_at_gmail.com> wrote:
>> >>
>> >> On Feb 9, 2012 1:23 PM, "Paul Burba" <ptburba_at_gmail.com> wrote:
>> >>>
>> >>> On Thu, Feb 9, 2012 at 11:49 AM, Daniel Shahaf <danielsh_at_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_at_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
Received on 2012-02-10 01:03:17 CET