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

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

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Thu, 9 Feb 2012 11:44:52 +0100

On Thu, Feb 9, 2012 at 10:45 AM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> Johan Corveleyn <jcorvel_at_gmail.com> 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: 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: 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
>
> So this is what I expected, the problem is the close_directory between
> open_file and close_file.  Because svnrdump doesn't implement a file
> baton but instead just uses the edit baton to handle a single file, the
> close_directory causes the file properties to be written early while the
> text is written later in close_file.
>
> What I don't understand is how close_directory gets called between
> open_file and close_file.  When libsvn_ra_serf calls open_file it does
> so from libsvn_ra_serf/update.c:handle_fetch and later in that same
> close_file is called.  How does close_directory get invoked between the
> two?  What is the callstack when close_directory is called?

I'll do some more experiments tonight.

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. But I'm still using
Visual C Express 2008 here (the "free" version), and I'm not sure if
that supports conditional breakpoints. And besides, I'm not sure what
condition I could use ...

Or can I simply write the callstack to stdout/stderr somehow at that
point, without erroring out?

What's still very mysterious about all this:
- Why doesn't this bug present itself with mod_dav_svn from trunk.
- Why does it only show up on Windows.

But I like a little mystery now and then, so ... we'll see.

-- 
Johan
Received on 2012-02-09 11:45:53 CET

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