subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <danie...@elego.de>
Subject Re: Failing svnrdump_tests.py#43 with 1.7.x on Windows
Date Thu, 09 Feb 2012 11:38:40 GMT
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@wandisco.com> wrote:
> > Johan Corveleyn <jcorvel@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

Mime
View raw message