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