Well, we have several user reports of crashes in libapr.dll on Windows.
1. Crash on svn export and svn checkout:
Mail: http://svn.haxx.se/dev/archive-2006-09/0738.shtml
Minudump can be found here: http://mysite.verizon.net/jodys7/svn.dmp
2. Another crash on svn export reported to me directly
Minidump can be found here: http://chemodax.googlepages.com/svn.dmp
3. Crash at same place when executing svn merge
Mail: http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=120663
I've asked for minidump to look on it, but we already have stack trace.
So all of these three crashes occur at same place:
libapr.dll!find_entry
libapr.dll!apr_hash_get
svn.exe!get_xlate_handle_node
svn.exe!svn_cmdline_cstring_from_utf8
svn.exe!svn_cmdline_printf
And at least cases (1) and (2) have workaround by renaming
TortoiseSVN's libapr_tsvn.dll to libapr.dll. So my initial idea was
some DLL hell, but uninstalling TortoiseSVN doesn't help!
I've looked to source code of function get_xlate_handle_node
(libsvn_subr/utf.c):
if (userdata_key)
{
if (xlate_handle_hash)
{
#if APR_HAS_THREADS
apr_err = apr_thread_mutex_lock(xlate_handle_mutex);
if (apr_err != APR_SUCCESS)
return svn_error_create(apr_err, NULL,
_("Can't lock charset translation mutex"));
#endif
old_node_p = apr_hash_get(xlate_handle_hash, userdata_key,
APR_HASH_KEY_STRING);
if (old_node_p)
old_node = *old_node_p;
And notice that one minidump has xlate_handle_hash == 0, but other has
xlate_handle_hash==0x00af00d0. How is it possible if we check it
several lines before?? But maybe it's problem with minidump format.
I'm continue investigating this problem and will be glad to any
suggestions/pointers.
--
Ivan Zhakov
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 10 17:55:04 2006