You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "D.J. Heap" <dj...@shadyvale.net> on 2004/05/12 01:25:19 UTC
Tests fail on Win32 with ra_dav and fsfs
On Windows the ra_dav + fstype=fsfs tests fail and crash Apache because
txn->vtable appears to be null.
ra_svn and ra_local pass all tests with fstype=fsfs.
Can someone else confirm or deny?
Here's the callstack:
> mod_dav_svn.so!svn_fs_txn_prop
mod_dav_svn.so!get_value
mod_dav_svn.so!dav_svn_db_get_rollback
mod_dav.so!dav_prop_exec
mod_dav.so!dav_method_proppatch
mod_dav.so!dav_handler
libhttpd.dll!ap_run_handler
libhttpd.dll!ap_invoke_handler
libhttpd.dll!ap_process_request
libhttpd.dll!ap_process_http_connection
libhttpd.dll!ap_run_process_connection
libhttpd.dll!ap_process_connection
libhttpd.dll!worker_main
msvcr71.dll!_threadstartex
KERNEL32.DLL!_BaseThreadStart@8
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tests fail on Win32 with ra_dav and fsfs
Posted by Greg Hudson <gh...@MIT.EDU>.
I wrote:
> * Clarify what happens to the txn ID after a successful commit...
> * Change FSFS not to purge the transaction on svn_fs_commit_txn.
> * Change the libsvn_repos commit editor to re-open and purge the
> transaction after committing it.
I had a closer look at mod_dav_svn and discovered that it keeps a
little mini-database mapping activity IDs to transaction IDs (because
activity IDs are client-specified and transaction IDs are
server-specified). This allowed me to develop a much simpler fix for
the problem, touching only mod_dav_svn. I did that in r9736.
The test suite passes over ra_dav with FSFS now except for log-tests 3
(log of an empty repository), which I will look into shortly.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tests fail on Win32 with ra_dav and fsfs
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> The client is behaving just fine from a DeltaV perspective, which is
> good because we couldn't rely on a client-side fix anyway. After much
> consideration, I think the correct solution is to:
>
> * Clarify what happens to the txn ID after a successful commit, in the
> svn_fs_commit_txn docstring. (Exactly what we should say is open to a
> little bit of debate. Certainly, one should not expect to be able to
> write to the transaction, since the txn becomes immutable under BDB.
> But one should be able to open it, and attempting to purge it should
> either succeed or yield a predictable error.)
>
> * Change FSFS not to purge the transaction on svn_fs_commit_txn. We
> can either leave it alone, assuming that the caller will re-open and
> purge the transaction, or we can gut it but leave the transaction
> directory around, much like a zombie Unix process, so that it can be
> opened and finished off.
>
> * Change the libsvn_repos commit editor to re-open and purge the
> transaction after committing it. (The re-open is necessary because
> svn_fs_commit_txn is documented as invalidating the txn object, though I
> don't know if there's a good reason for that.)
A related (but not urgent) blue-sky point that may affect our thinking
about FSFS:
We've talked a bit about "svn submit" as a more tentative version of
"svn commit", whereby one would create a txn but not commit it.
Someone else could then review the txn, and promote it / reject it /
promote to a branch / whatever. So I think it's fine if txn purging
is a client responsibility, but would worry if txn purging were ever
required or enforced by the server-side. You don't seem to be
suggesting the latter; I just wanted to mention this now, so we think
about txns as potentially first-class, user-visible objects.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tests fail on Win32 with ra_dav and fsfs
Posted by "D.J. Heap" <dj...@shadyvale.net>.
Greg Hudson wrote:
>
> I think you misinterpreted slightly. The first DELETE request fails
> with FSFS when it tries to open the transaction, since svn_fs_commit_txn
> invalidated the transaction ID. That's the real source of the error. A
> second DELETE request comes in when the client sees close_edit() fail
> and invokes abort_edit().
[snip]
Yes, I did -- thanks for the concise explanation and correction.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tests fail on Win32 with ra_dav and fsfs
Posted by Greg Hudson <gh...@MIT.EDU>.
I can reproduce this problem under Linux, fortunately, so I know what's
going on.
On Wed, 2004-05-12 at 22:56, D.J. Heap wrote:
> Some more info on this -- the commit actually succeeds and the
> repository seems to be fine. However, a second DELETE for the activity
> comes through and fails because the transaction directory has already
> been removed. The 2nd DELETE doesn't happen with fstype=bdb.
I think you misinterpreted slightly. The first DELETE request fails
with FSFS when it tries to open the transaction, since svn_fs_commit_txn
invalidated the transaction ID. That's the real source of the error. A
second DELETE request comes in when the client sees close_edit() fail
and invokes abort_edit().
In BDB, opening the transaction after committing it succeeds; the
attempt to purge the transaction fails with
SVN_ERR_FS_TRANSACTION_NOT_MUTABLE, which mod_dav_svn catches and
ignores.
> It kind of seems like a client problem, but I don't know how the client
> could know the difference? Or can DELETE's be initiated without the
> client somehow?
The client is behaving just fine from a DeltaV perspective, which is
good because we couldn't rely on a client-side fix anyway. After much
consideration, I think the correct solution is to:
* Clarify what happens to the txn ID after a successful commit, in the
svn_fs_commit_txn docstring. (Exactly what we should say is open to a
little bit of debate. Certainly, one should not expect to be able to
write to the transaction, since the txn becomes immutable under BDB.
But one should be able to open it, and attempting to purge it should
either succeed or yield a predictable error.)
* Change FSFS not to purge the transaction on svn_fs_commit_txn. We
can either leave it alone, assuming that the caller will re-open and
purge the transaction, or we can gut it but leave the transaction
directory around, much like a zombie Unix process, so that it can be
opened and finished off.
* Change the libsvn_repos commit editor to re-open and purge the
transaction after committing it. (The re-open is necessary because
svn_fs_commit_txn is documented as invalidating the txn object, though I
don't know if there's a good reason for that.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tests fail on Win32 with ra_dav and fsfs
Posted by "D.J. Heap" <dj...@shadyvale.net>.
[snip]
>
> START: basic_tests.py
> CMD: svnadmin.exe "create" "local_tmp\repos" "--bdb-txn-nosync"
> "--fs-type" "fsfs" <TIME = 0.109000>
> CMD: svn.exe "import" "--username" "jrandom" "--password" "rayjandom"
> "-m" "Log message for revision 1." "local_tmp\greekfiles"
> "http://localhost/local_tmp/repos" "--config-dir"
> "D:\Temp\junk\subversion\tests\clients\cmdline\local_tmp\config" <TIME =
> 0.562000>
> svn:
> No such transaction.
>
>
Some more info on this -- the commit actually succeeds and the
repository seems to be fine. However, a second DELETE for the activity
comes through and fails because the transaction directory has already
been removed. The 2nd DELETE doesn't happen with fstype=bdb.
It kind of seems like a client problem, but I don't know how the client
could know the difference? Or can DELETE's be initiated without the
client somehow?
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tests fail on Win32 with ra_dav and fsfs
Posted by "D.J. Heap" <dj...@shadyvale.net>.
Greg Hudson wrote:
>>On Windows the ra_dav + fstype=fsfs tests fail and crash Apache
>>because txn->vtable appears to be null.
>
>
> Thanks for noticing this. Please try again with r9689 or higher.
>
Thanks -- it no longer crashes but I get 'No such transaction' errors
(only with ra_dav) on commits now:
START: basic_tests.py
CMD: svnadmin.exe "create" "local_tmp\repos" "--bdb-txn-nosync"
"--fs-type" "fsfs" <TIME = 0.109000>
CMD: svn.exe "import" "--username" "jrandom" "--password" "rayjandom"
"-m" "Log message for revision 1." "local_tmp\greekfiles"
"http://localhost/local_tmp/repos" "--config-dir"
"D:\Temp\junk\subversion\tests\clients\cmdline\local_tmp\config" <TIME =
0.562000>
svn:
No such transaction.
I can do some debugging tomorrow night if needed.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tests fail on Win32 with ra_dav and fsfs
Posted by Greg Hudson <gh...@MIT.EDU>.
> On Windows the ra_dav + fstype=fsfs tests fail and crash Apache
> because txn->vtable appears to be null.
Thanks for noticing this. Please try again with r9689 or higher.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org