On Wed, 2004-10-20 at 19:26 +0100, Philip Martin wrote:
> Martin MAURER <martin.maurer@email.de> writes:
>
> > #0 0x402c5781 in kill () from /lib/libc.so.6
> > #1 0x40247e5e in pthread_kill () from /lib/libpthread.so.0
> > #2 0x40248339 in raise () from /lib/libpthread.so.0
> > #3 0x402c6be1 in abort () from /lib/libc.so.6
> > #4 0x4009bb72 in begin_trail (trail_p=0xbffff7a4, fs=0x817f0d8,
> > use_txn=1,
> > pool=0x8061f38) at subversion/libsvn_fs_base/trail.c:111
> > #5 0x4009bd57 in do_retry (fs=0x817f0d8,
> > txn_body=0x4009b950 <txn_body_abort_txn>, baton=0x818c290,
> > use_txn=1,
> > pool=0x8061f38, txn_body_fn_name=0x400a5b2d "unknown",
> > filename=0x400a5b2c "", line=0) at
> > subversion/libsvn_fs_base/trail.c:229
> > #6 0x4009be5a in svn_fs_base__retry_txn (fs=0x817f0d8,
> > txn_body=0x4009b950 <txn_body_abort_txn>, baton=0x818c290,
> > pool=0x8061f38)
> > at subversion/libsvn_fs_base/trail.c:291
> > #7 0x4009b9f8 in svn_fs_base__abort_txn (txn=0x818c290, pool=0x8061f38)
> > at subversion/libsvn_fs_base/revs-txns.c:917
> > #8 0x40073509 in svn_fs_abort_txn (txn=0x818c290, pool=0x8061f38)
> > at subversion/libsvn_fs/fs-loader.c:416
> > #9 0x4006175c in abort_edit (edit_baton=0x817be60, pool=0x8061f38)
> > at subversion/libsvn_repos/commit.c:599
>
> It looks like the commit failed before the crash, and the client then
> crashed while aborting the commit.
>
> > #10 0x4001d108 in svn_client_commit (commit_info=0xbffff9b4,
> > targets=0x8062e20, nonrecursive=0, ctx=0x80625b8, pool=0x8061f38)
> > at subversion/libsvn_client/commit.c:1431
> > #11 0x0804c0c8 in svn_cl__commit (os=0x8061f70, baton=0xbffffa28,
> > ---Type <return> to continue, or q <return> to quit---
> > pool=0x8061f38) at subversion/clients/cmdline/commit-cmd.c:94
> > #12 0x0804eecd in main (argc=4, argv=0xbffffca4)
> > at subversion/clients/cmdline/main.c:1332
>
> > svnadmin recover works, but checking in again fails again.
>
> With the same gdb stack?
yes the stack trace stays the same when i repeat this.
(i didnt activate coredumping [via ulimit] when this happened the first
time. but since then - this stack trace)
>
> > unfortunately the data is company data, so i cant make it available.
> >
> > what should i try next ? any way to check if the server works - and get
> > a coredump out of it (if it crashes)
>
> There is no server, it's the client itself you need to debug. If you
> can't do that then you need to provide enough information to allow
> someone else to reproduce the problem.
i dont know enough about subversion to debug it at the moment (and i got
limited time). I know some c/c++, so i can do minor changes if needed.
If you need further information, please tell me which. would an strace
help ?
greetings
--
Martin MAURER <martin.maurer@email.de>
Received on Thu Oct 21 20:53:30 2004