Re: deltification questions

Hi all,

I continued debugging this problem and started using gdb.
Problem is I dont know a lot about the subversion code, and so I send
you my current status - maybe you know more about this:

I set a breakpoint when the revision which had problems, started eating
memory. This breakpoint is still inside the loop in question, as
using "cont" (in gdb) resulted in reaching that breakpoint again, while
svnadmin's memory consumption was rising.

when I looked at the following backtrace, I realized that a function
called do_retry has been called and i guess this already indicates a
problem.

Any further suggestions on where I should continue debugging ?

greetings
Martin

(gdb) cont
Continuing.

Breakpoint 5, rep_read_contents (baton=0x80f4fe8, buf=0x0, len=0x0)
    at subversion/libsvn_fs/reps-strings.c:893
893 return SVN_NO_ERROR;
(gdb) bt
#0 rep_read_contents (baton=0x80f4fe8, buf=0x0, len=0x0)
    at subversion/libsvn_fs/reps-strings.c:893
#1 0x400661b3 in svn_stream_read (stream=0xedde5f, buffer=0x0, len=0x0)
    at subversion/libsvn_subr/stream.c:97
#2 0x400506a6 in svn_txdelta_next_window (window=0xbffff428,
    stream=0x8112ad8, pool=0x81167b0)
    at subversion/libsvn_delta/text_delta.c:264
#3 0x4003bd71 in svn_fs__rep_deltify (fs=0x80718f0, target=0x80f4e00
"1t",
    source=0x80f4fa8 "21", trail=0x80e8968)
    at subversion/libsvn_fs/reps-strings.c:1387
#4 0x40037562 in svn_fs__dag_deltify (target=0x80f4da8, source=0x0,
    props_only=0, trail=0x80e8968) at subversion/libsvn_fs/dag.c:1505
#5 0x4003fa81 in txn_body_txn_deltify (baton=0xbffff5f0,
trail=0x80e8968)
    at subversion/libsvn_fs/tree.c:1570
#6 0x4003db88 in do_retry (fs=0x80718f0,
    txn_body=0x4003f9f0 <txn_body_txn_deltify>, baton=0xbffff5f0,
use_txn=1,
    pool=0x80e87a0, txn_body_fn_name=0x40048e4d "unknown",
    filename=0x40048e4c "", line=0) at subversion/libsvn_fs/trail.c:227
#7 0x4003dca7 in svn_fs__retry_txn (fs=0x0, txn_body=0, baton=0x0,
pool=0x0)
    at subversion/libsvn_fs/trail.c:285
#8 0x4003fe0b in deltify_mutable (fs=0x80718f0, root=0x4,
    path=0x80e8940 "P\211\016\bX\211\016\b`\211\016\b", txn_id=0x80c87b8
"x",
    pool=0x80e87a0) at subversion/libsvn_fs/tree.c:1763
#9 0x4003fcab in deltify_mutable (fs=0x80718f0, root=0x80c6750,
    path=0x400470be "/", txn_id=0x80c87b8 "x", pool=0x809b340)
    at subversion/libsvn_fs/tree.c:1663
#10 0x4004139f in svn_fs_deltify_revision (fs=0x80718f0, revision=33,
    pool=0x809b340) at subversion/libsvn_fs/tree.c:2804
#11 0x40021d94 in close_revision (baton=0x809b378)
    at subversion/libsvn_repos/load.c:954
#12 0x40020e80 in svn_repos_parse_dumpstream (stream=0x8051850,
    parse_fns=0x80518c0, parse_baton=0x80518e8,
    cancel_func=0x80496b0 <check_cancel>, cancel_baton=0x0,
pool=0x80513e0)
    at subversion/libsvn_repos/load.c:467
#13 0x40021fc2 in svn_repos_load_fs (repos=0x0, dumpstream=0x0,
    feedback_stream=0x0, uuid_action=svn_repos_load_uuid_default,
    parent_dir=0x0, cancel_func=0, cancel_baton=0x0, pool=0x80513e0)
    at subversion/libsvn_repos/load.c:1050
#14 0x08049e7d in subcommand_load (os=0x8051418, baton=0xbffff940,
    pool=0x80496b0) at subversion/svnadmin/main.c:515
#15 0x0804ab67 in main (argc=134518432, argv=0x0)
    at subversion/svnadmin/main.c:1051

On Tue, 2004-01-13 at 16:47, kfogel@collab.net wrote:
> Martin, did you ever find out more about this?
>
> It's not a symptom we've seen much before; I don't know what might be
> causing it. Does it still reproduce with HEAD of trunk, or with the
> 1.0-stabilization branch? 0.36 will be out very soon, too, could try
> with that.
>
> -Karl
>
> Martin MAURER <martinmaurer@gmx.at> writes:
> > On Sun, 2003-12-14 at 00:33, C. Michael Pilato wrote:
> > > Martin MAURER <martinmaurer@gmx.at> writes:
> > >
> > > > if I switch to svn 0.34, and do a dump and load on this repo,
> > > > will this then be deltificated ?
> > >
> > > Yes. 'svnadmin load' deltifies each revision as it is added to your
> > > repository.
> > >
> > I just tried svn version 0.35.0 (checked out the branch via svn).
> > I am getting reproducible problems with svnadmin load:
> >
> > gunzip -c /backup/svn/SVN_databases_2003_12_14.gz | svnadmin load
> > SVN_databases
> >
> >
> > <<< Started new transaction, based on original revision 31
> > * editing path : guute_devel.sql ... done.
> >
> > ------- Committed revision 31 >>>
> >
> > <<< Started new transaction, based on original revision 32
> > * editing path : guute_devel.sql ... done.
> >
> > ------- Committed revision 32 >>>
> >
> > <<< Started new transaction, based on original revision 33
> > * editing path : guute_devel.sql ... done.
> > Killed
> >
> > svnadmin gets Killed, because it uses up all my memory:
> > PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
> > 19111 lonestar 17 0 507M 104M 864 R 38.0 84.0 18:25 svnadmin
> >
> > (part of top shortly before it gets killed)
> >
> >
> > I have got the following installation:
> > Berkeley DB 4.2.52
> > httpd 2.0.48's apr, aprutil
> > subversion 0.35.0 (checked out on Sun 14)
> > access method: file:///
> >
> > this issue isnt a bigger problem for me, but I think it should be
> > resolved.
> >
> > The problem is, that the data I am talking about is company data,
> > so I can't easily make it available.
> >
> > The svndump was done with svn 0.33.1
> > there are 8 files in the repository
> > 2 of them need about 40 mb space
> > the files are dumps from a mysql database (using mysqldump),
> > the revisions are created by doing daily dumps of these databases.
> > the latest Revision-number in the dumpfile is 43
> >
> > Is there anything I could try ?
> > (maybe some easy way to disable deltification, to see if the bug is part
> > of that code, or something like that)
> >
> > greetings
> > Martin
>