On Thu, Feb 9, 2012 at 2:33 AM, Johan Corveleyn <jcorvel_at_gmail.com> 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 file D/H/psi is split incorrectly (property content is dumped
> early, and text delta later).
>
> - It only happens on Windows.
>
> - It only happens with ra_serf (both 1.7.x. and trunk) talking to
> mod_dav_svn from 1.7.x@>=1239697 (i.e. after backport of r1237720 and
> r1239596 (stuff in mod_dav_svn/liveprops.c) from trunk).
>
> - If 1.7.x is rolled back to before r1239697, the problem does not occur.
>
> - The problem does not occur with mod_dav_svn from trunk, not even
> when rolled back to (before or after) r1237720 or r1239596.
>
> - So far, it has been reproduced by the buildbot svn-slik-w2k3-x64-ra,
> by Stephen Butler, and by my own (32bit) WinXP box. Paul Burba doesn't
> see the failure with his Windows build (debug and release).
>
>
> I'm trying some more experiments. If anyone else has any ideas, shoot ...
On Tue, Feb 7, 2012 at 1:11 PM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> "roderich.schupp_at_googlemail.com" <roderich.schupp_at_googlemail.com>
> writes:
>
>> It's definitely an ordering problem, look at the whole series of operations:
>>
>> ...
>> add file trunk/D/H/omega
>> add file trunk/D/H/psi <--- the one with the bogus split props/text
>> add dir branches
>> add dir trunk/C
>> add dir trunk/B/F
>> ...
>>
>> "branches" starts while "trunk/..." has not finished yet.
>> Also "trunk/B/.." continues though already "trunk/D/..." has started.
>
> On my Linux box neon gives me:
>
> DBG: dump_editor.c: 546: add_file trunk/D/H/omega
> DBG: dump_editor.c: 669: change_file_prop 0xf76820
> DBG: dump_editor.c: 669: change_file_prop 0xf76820
> DBG: dump_editor.c: 669: change_file_prop 0xf76820
> DBG: dump_editor.c: 669: change_file_prop 0xf76820
> DBG: dump_editor.c: 669: change_file_prop 0xf76820
> DBG: dump_editor.c: 719: apply_textdelta 0xf76820
> DBG: dump_editor.c: 750: close_file 0xf76820
> DBG: dump_editor.c: 546: add_file trunk/D/H/psi
> DBG: dump_editor.c: 669: change_file_prop 0x1333820
> DBG: dump_editor.c: 669: change_file_prop 0x1333820
> DBG: dump_editor.c: 669: change_file_prop 0x1333820
> DBG: dump_editor.c: 669: change_file_prop 0x1333820
> DBG: dump_editor.c: 669: change_file_prop 0x1333820
> DBG: dump_editor.c: 719: apply_textdelta 0x1333820
> DBG: dump_editor.c: 750: close_file 0x1333820
> DBG: dump_editor.c: 512: close_directory 0x1304148
> DBG: dump_editor.c: 512: close_directory 0x1303780
> DBG: dump_editor.c: 512: close_directory 0x13026b8
> DBG: dump_editor.c: 432: add_directory branches
>
> while serf gives me:
>
> DBG: dump_editor.c: 546: add_file trunk/D/H/omega
> DBG: dump_editor.c: 719: apply_textdelta 0x19be798
> DBG: dump_editor.c: 669: change_file_prop 0x19be798
> DBG: dump_editor.c: 669: change_file_prop 0x19be798
> DBG: dump_editor.c: 669: change_file_prop 0x19be798
> DBG: dump_editor.c: 669: change_file_prop 0x19be798
> DBG: dump_editor.c: 669: change_file_prop 0x19be798
> DBG: dump_editor.c: 750: close_file 0x19be798
> DBG: dump_editor.c: 546: add_file trunk/D/H/psi
> DBG: dump_editor.c: 719: apply_textdelta 0x1ff8798
> DBG: dump_editor.c: 669: change_file_prop 0x1ff8798
> DBG: dump_editor.c: 669: change_file_prop 0x1ff8798
> DBG: dump_editor.c: 669: change_file_prop 0x1ff8798
> DBG: dump_editor.c: 669: change_file_prop 0x1ff8798
> DBG: dump_editor.c: 669: change_file_prop 0x1ff8798
> DBG: dump_editor.c: 750: close_file 0x1ff8798
> DBG: dump_editor.c: 432: add_directory branches
>
> Both of those orders work.
>
> The dump editor used by svnrdump doesn't use an explicit file baton, it
> simply uses the editor baton to collect the data for the "current" file.
> Assuming our editor API allows multiple files to be open at the same
> time then svnrdump probably needs to grow a dedicated file baton and use
> that in close_file.
Ok, I also enabled "#define LDR_DBG(x) SVN_DBG(x)" in dump_editor.c,
and when running the test I see the following when the corrupt dump
file is produced (this happens with "svnrdump.exe -q dump -r1:10 ..."
in svnrdump_tests.py line 543):
With svnrdump_at_trunk vs. mod_dav_svn_at_1.7.x_at_HEAD:
...
DBG: dump_editor.c: 552: add_file trunk/D/H/omega
DBG: dump_editor.c: 725: apply_textdelta 0112B188
DBG: dump_editor.c: 675: change_file_prop 0112B188
DBG: dump_editor.c: 675: change_file_prop 0112B188
DBG: dump_editor.c: 675: change_file_prop 0112B188
DBG: dump_editor.c: 675: change_file_prop 0112B188
DBG: dump_editor.c: 675: change_file_prop 0112B188
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: 633: change_dir_prop 01150F00
DBG: dump_editor.c: 633: change_dir_prop 01150F00
DBG: dump_editor.c: 633: change_dir_prop 01150F00
DBG: dump_editor.c: 518: close_directory 01150F00
DBG: dump_editor.c: 675: change_file_prop 0112B188
DBG: dump_editor.c: 675: change_file_prop 0112B188
DBG: dump_editor.c: 675: change_file_prop 0112B188
DBG: dump_editor.c: 675: change_file_prop 0112B188
DBG: dump_editor.c: 675: change_file_prop 0112B188
DBG: dump_editor.c: 756: close_file 0112B188
DBG: dump_editor.c: 633: change_dir_prop 01151240
DBG: dump_editor.c: 633: change_dir_prop 01151240
DBG: dump_editor.c: 633: change_dir_prop 01151240
DBG: dump_editor.c: 633: change_dir_prop 01151240
DBG: dump_editor.c: 633: change_dir_prop 01151240
DBG: dump_editor.c: 518: close_directory 01151240
DBG: dump_editor.c: 633: change_dir_prop 01150D18
DBG: dump_editor.c: 633: change_dir_prop 01150D18
DBG: dump_editor.c: 633: change_dir_prop 01150D18
DBG: dump_editor.c: 633: change_dir_prop 01150D18
DBG: dump_editor.c: 633: change_dir_prop 01150D18
DBG: dump_editor.c: 518: close_directory 01150D18
DBG: dump_editor.c: 438: add_directory branches
...
With svnrdump_at_trunk vs. mod_dav_svn_at_1.7.x_at_1239696 (no corruption):
...
DBG: dump_editor.c: 552: add_file trunk/D/H/omega
DBG: dump_editor.c: 725: apply_textdelta 0112B188
DBG: dump_editor.c: 675: change_file_prop 0112B188
DBG: dump_editor.c: 675: change_file_prop 0112B188
DBG: dump_editor.c: 675: change_file_prop 0112B188
DBG: dump_editor.c: 675: change_file_prop 0112B188
DBG: dump_editor.c: 675: change_file_prop 0112B188
DBG: dump_editor.c: 756: close_file 0112B188
DBG: dump_editor.c: 633: change_dir_prop 01150F00
DBG: dump_editor.c: 633: change_dir_prop 01150F00
DBG: dump_editor.c: 633: change_dir_prop 01150F00
DBG: dump_editor.c: 633: change_dir_prop 01150F00
DBG: dump_editor.c: 633: change_dir_prop 01150F00
DBG: dump_editor.c: 518: close_directory 01150F00
DBG: dump_editor.c: 552: add_file trunk/D/H/psi
DBG: dump_editor.c: 725: apply_textdelta 0112B188
DBG: dump_editor.c: 675: change_file_prop 0112B188
DBG: dump_editor.c: 675: change_file_prop 0112B188
DBG: dump_editor.c: 675: change_file_prop 0112B188
DBG: dump_editor.c: 675: change_file_prop 0112B188
DBG: dump_editor.c: 675: change_file_prop 0112B188
DBG: dump_editor.c: 756: close_file 0112B188
DBG: dump_editor.c: 633: change_dir_prop 01151240
DBG: dump_editor.c: 633: change_dir_prop 01151240
DBG: dump_editor.c: 633: change_dir_prop 01151240
DBG: dump_editor.c: 633: change_dir_prop 01151240
DBG: dump_editor.c: 633: change_dir_prop 01151240
DBG: dump_editor.c: 518: close_directory 01151240
DBG: dump_editor.c: 633: change_dir_prop 01150D18
DBG: dump_editor.c: 633: change_dir_prop 01150D18
DBG: dump_editor.c: 633: change_dir_prop 01150D18
DBG: dump_editor.c: 633: change_dir_prop 01150D18
DBG: dump_editor.c: 633: change_dir_prop 01150D18
DBG: dump_editor.c: 518: close_directory 01150D18
DBG: dump_editor.c: 438: add_directory branches
...
Any ideas?
BTW: for some reason, the test now also fails with this last test-run
(with mod_dav_svn_at_1.7.x_at_1239696), but with another failure:
"svnrdump: E140001: Dump stream contains a malformed header (with no
':') at 'ile_prop 0112B188'"
However, that piece of text is output from the DBG statements. For
some reason it interferes with the stream that 'svnrdump load' is
trying to read. So that may also be a problem, though probably
unrelated to the one we're investigating here.
--
Johan
Received on 2012-02-09 04:04:53 CET