Re: Failing svnrdump_tests.py#43 with 1.7.x on Windows

Johan Corveleyn writes: > 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))' (co

Re: Failing svnrdump_tests.py#43 with 1.7.x on Windows (was: Re: 1.7.3 next week-ish?)

On Thu, Feb 9, 2012 at 9:55 PM, Greg Stein wrote: > > On Feb 9, 2012 3:07 PM, "Paul Burba" wrote: >> >> On Thu, Feb 9, 2012 at 2:50 PM, Johan Corveleyn wrote: >> > On Thu, Feb 9, 2012 at 7:59 PM, Greg Stein wrote: >> >> >> >> On Feb 9, 2012 1:23 PM, "Paul Burba" wrote: >> >>> >> >>> On Thu, Fe

Re: Failing svnrdump_tests.py#43 with 1.7.x on Windows (was: Re: 1.7.3 next week-ish?)

On Feb 9, 2012 3:07 PM, "Paul Burba" wrote: > > On Thu, Feb 9, 2012 at 2:50 PM, Johan Corveleyn wrote: > > On Thu, Feb 9, 2012 at 7:59 PM, Greg Stein wrote: > >> > >> On Feb 9, 2012 1:23 PM, "Paul Burba" wrote: > >>> > >>> On Thu, Feb 9, 2012 at 11:49 AM, Daniel Shahaf wrote: > >>> >... > >> >

Re: Failing svnrdump_tests.py#43 with 1.7.x on Windows (was: Re: 1.7.3 next week-ish?)

On Thu, Feb 9, 2012 at 2:50 PM, Johan Corveleyn wrote: > On Thu, Feb 9, 2012 at 7:59 PM, Greg Stein wrote: >> >> On Feb 9, 2012 1:23 PM, "Paul Burba" wrote: >>> >>> On Thu, Feb 9, 2012 at 11:49 AM, Daniel Shahaf wrote: >>> >... >> >>> > It is suggested there that setting >>> > libsvn_ra_serf/up

Re: Failing svnrdump_tests.py#43 with 1.7.x on Windows (was: Re: 1.7.3 next week-ish?)

On Thu, Feb 9, 2012 at 7:59 PM, Greg Stein wrote: > > On Feb 9, 2012 1:23 PM, "Paul Burba" wrote: >> >> On Thu, Feb 9, 2012 at 11:49 AM, Daniel Shahaf wrote: >> >... > >> > It is suggested there that setting >> > libsvn_ra_serf/update.c:MAX_NR_OF_CONNS >> > to "2" will prevent ra_serf from drivi

Re: Failing svnrdump_tests.py#43 with 1.7.x on Windows (was: Re: 1.7.3 next week-ish?)

On Feb 9, 2012 1:23 PM, "Paul Burba" wrote: > > On Thu, Feb 9, 2012 at 11:49 AM, Daniel Shahaf 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

Re: Failing svnrdump_tests.py#43 with 1.7.x on Windows (was: Re: 1.7.3 next week-ish?)

On Thu, Feb 9, 2012 at 7:23 PM, Paul Burba wrote: [ ... ] > However, if I let the test suite start up httpd, then I *do* > consistently see the same failure: Wow, I wouldn't have thought of that as a discriminating factor. I'm running the server in a separate command window, just running httpd.

Re: Failing svnrdump_tests.py#43 with 1.7.x on Windows (was: Re: 1.7.3 next week-ish?)

On Thu, Feb 9, 2012 at 11:49 AM, Daniel Shahaf wrote: > Johan Corveleyn wrote on Thu, Feb 09, 2012 at 02:33:25 +0100: >> Having another look at this failure ... >> >> So far, we know (anyone, correct me if I'm wrong): >> >> - 'svnrdump load' in this test fails with: "svnrdump: E140001: >> Unrecogn

Re: Failing svnrdump_tests.py#43 with 1.7.x on Windows (was: Re: 1.7.3 next week-ish?)

Johan Corveleyn wrote on Thu, Feb 09, 2012 at 02:33:25 +0100: > Having another look at this failure ... > > So far, we know (anyone, correct me if I'm wrong): > > - 'svnrdump load' in this test fails with: "svnrdump: E140001: > Unrecognized record type in stream". It seems the dumpfile contents o

Re: Failing svnrdump_tests.py#43 with 1.7.x on Windows

Johan Corveleyn writes: > I'm not very experienced in debugging C code ... any hints on how to > get a hold of the callstack easily? I'd think of setting a breakpoint > there, but it would be best to do that with a conditional breakpoint > somehow, to avoid having to resume a dozen times. There

Re: Failing svnrdump_tests.py#43 with 1.7.x on Windows

Johan Corveleyn wrote on Thu, Feb 09, 2012 at 11:44:52 +0100: > On Thu, Feb 9, 2012 at 10:45 AM, Philip Martin > wrote: > > Johan Corveleyn writes: > > > >> DBG: dump_editor.c: 756: close_file 0112B188 > >> DBG: dump_editor.c: 552: add_file trunk/D/H/psi > >> DBG: dump_editor.c: 725: apply_textde

Re: Failing svnrdump_tests.py#43 with 1.7.x on Windows (was: Re: 1.7.3 next week-ish?)

Johan Corveleyn wrote on Thu, Feb 09, 2012 at 04:03:43 +0100: > BTW: for some reason, the test now also fails with this last test-run > (with mod_dav_svn@1.7.x@1239696), but with another failure: > > "svnrdump: E140001: Dump stream contains a malformed header (with no > ':') at 'ile_prop 0112B188'

Re: Failing svnrdump_tests.py#43 with 1.7.x on Windows

On Thu, Feb 9, 2012 at 10:45 AM, Philip Martin wrote: > Johan Corveleyn writes: > >> DBG: dump_editor.c: 756: close_file 0112B188 >> DBG: dump_editor.c: 552: add_file trunk/D/H/psi >> DBG: dump_editor.c: 725: apply_textdelta 0112B188 >> DBG: dump_editor.c: 633: change_dir_prop 01150F00 >> DBG: du

Re: Failing svnrdump_tests.py#43 with 1.7.x on Windows

Johan Corveleyn writes: > DBG: dump_editor.c: 756: close_file 0112B188 > DBG: dump_editor.c: 552: add_file trunk/D/H/psi > DBG: dump_editor.c: 725: apply_textdelta 0112B188 > DBG: dump_editor.c: 633: change_dir_prop 01150F00 > DBG: dump_editor.c: 633: change_dir_prop 01150F00 > DBG: dump_editor.c

Re: Failing svnrdump_tests.py#43 with 1.7.x on Windows (was: Re: 1.7.3 next week-ish?)

On Thu, Feb 9, 2012 at 2:33 AM, Johan Corveleyn wrote: > Having another look at this failure ... > > So far, we know (anyone, correct me if I'm wrong): > > - 'svnrdump load' in this test fails with: "svnrdump: E140001: > Unrecognized record type in stream". It seems the dumpfile contents of > the

Failing svnrdump_tests.py#43 with 1.7.x on Windows (was: Re: 1.7.3 next week-ish?)

Having another look at this failure ... So far, we know (anyone, correct me if I'm wrong): - 'svnrdump load' in this test fails with: "svnrdump: E140001: Unrecognized record type in stream". It seems the dumpfile contents of the file D/H/psi is split incorrectly (property content is dumped early,