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.mar...@wandisco.com> wrote: > > Johan Corveleyn <jcor...@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
