[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Win32 lock_tests 11 crashing

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2005-05-29 00:14:46 CEST

"D.J. Heap" <dj@shadyvale.net> writes:

> This test is crashing due to a NULL hashtable pointer with this callstack:
>
> libapr.dll!find_entry
> libapr.dll!apr_hash_get
> svn.exe!store_locks_callback
> svn.exe!svn_ra_local__unlock
> svn.exe!svn_ra_unlock
> svn.exe!svn_client_unlock
> svn.exe!svn_cl__unlock
> svn.exe!main
> svn.exe!mainCRTStartup
> kernel32.dll!_BaseProcessStart@4
>
> It appears to be related to the r14862 family of changes?

It's not just win32, 'svn unlock URL' is broken on all platforms.
When svn_client_unlock passes URLs to organize_lock_targets it gets
back a NULL urls_to_paths hash, as documented. This gets stored in
the lock_baton passed to store_locks_callback which doesn't handle a
NULL hash.

> The test still passes after the crash, though.

The test should really be using run_and_verify_status to check what
happened, but in this case it would not help since the crash occurs
after the repository has unlocked. Unlocking two URLs would detect
the problem, the crash would prevent the second URL getting unlocked.

Look at the next test, lock_unlock, it barely does any checking at
all! It certainly doesn't verify that any locks get created or
released.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 29 00:15:38 2005

This is an archived mail posted to the Subversion Dev mailing list.