Johan Corveleyn wrote on Thu, Feb 09, 2012 at 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
Are you aware of the wrapper editor debug_editor.c?
> 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 ...
Well, you could just print the call stack unconditionally (look for
VC-specific means to do that). Otherwise, I suppose a global variable
(or an envvar) such as SEEN_THE_FIRST_close_file_CALL would do nicely.
>
> 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.
>
Yes, ra_serf-specific, branch-specific, windows-specific at the same
time. Odd.
As another angle: why does the bug not trigger for Paul? Is it due to
his build flags, or due to his version of (mod_dav|apr|Windows|libserf)?
> But I like a little mystery now and then, so ... we'll see.
>
> --
> Johan
Received on 2012-02-09 12:39:25 CET