You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Chris AtLee <ch...@atlee.ca> on 2006/10/05 18:32:33 UTC
Crash with svn 1.4.0
Hello,
Sorry if this is a duplicate post, I sent this message yesterday and
didn't see it appear in the mailing list archives, so I figured I'd
subscribe and try again.
I can semi-reliably reproduce a crash with svn 1.4.0 if I interrupt it
soon after starting a 'svn status' command. It seems to only crash if I
interrupt it before any output has been generated (while it's locking
the wc?) My working copy is fairly large (a few hundred megs), so there
is often a few seconds before any status information is output. It runs
clean under valgrind except for an "Invalid read of size 4" at
apr_hash.c:117, which isn't too surprising.
Please let me know if there's any other information I can make available
to help track this down.
Thanks,
Chris
Here's the backtrace of the crash:
#0 apr_hash_next (hi=0x85e32e8) at apr_hash.c:117
#1 0xb7f40f8e in svn_sort__hash (ht=0x808f5a0,
comparison_func=0x804abd0 <sv...@plt>,
pool=0x8095310) at subversion/libsvn_subr/sorts.c:131
#2 0xb7f8b746 in do_close (adm_access=0x8507b18, preserve_lock=0,
recurse=1) at subversion/libsvn_wc/lock.c:1288
#3 0xb7f899d8 in pool_cleanup (p=0x8507b18) at
subversion/libsvn_wc/lock.c:395
#4 0xb7dd7d8d in run_cleanups (cref=0x8095320) at apr_pools.c:1959
#5 0xb7dd866d in apr_pool_destroy (pool=0x8095310) at apr_pools.c:731
#6 0xb7dd8658 in apr_pool_destroy (pool=0x80721a8) at apr_pools.c:728
#7 0x08053054 in main (argc=2, argv=0xbf9bdd74) at
subversion/svn/main.c:1505
rooneg on #svn-dev suggested I check to see where svn_cl__check_cancel
was being called from, so here's that trace:
#0 svn_cl__check_cancel (baton=0x0) at subversion/svn/main.c:806
#1 0xb7ecd1ab in do_open (adm_access=0xbfc70090, associated=0x890bde0,
path=0x88d9030 "XXXXXX/document/src/commands/commands", write_lock=0,
depth=-1, under_construction=0,
cancel_func=0x805161d <svn_cl__check_cancel>, cancel_baton=0x0,
pool=0x8095310) at subversion/libsvn_wc/lock.c:646
#2 0xb7ecd28b in do_open (adm_access=0xbfc70120, associated=0x89062b0,
path=0x86e2ba8 "XXXXXX/document/src/commands", write_lock=0, depth=-1,
under_construction=0, cancel_func=0x805161d <svn_cl__check_cancel>,
cancel_baton=0x0, pool=0x8095310) at subversion/libsvn_wc/lock.c:664
#3 0xb7ecd28b in do_open (adm_access=0xbfc701b0, associated=0x8559ca8,
path=0x80a2dc0 "XXXXXX/document/src", write_lock=0, depth=-1,
under_construction=0, cancel_func=0x805161d <svn_cl__check_cancel>,
cancel_baton=0x0, pool=0x8095310) at subversion/libsvn_wc/lock.c:664
#4 0xb7ecd28b in do_open (adm_access=0xbfc70240, associated=0x8098248,
path=0x82706c8 "XXXXXX/document", write_lock=0, depth=-1,
under_construction=0, cancel_func=0x805161d <svn_cl__check_cancel>,
cancel_baton=0x0, pool=0x8095310) at subversion/libsvn_wc/lock.c:664
#5 0xb7ecd28b in do_open (adm_access=0xbfc702d0, associated=0x8095430,
path=0x8088b70 "XXXXXX", write_lock=0, depth=-1, under_construction=0,
cancel_func=0x805161d <svn_cl__check_cancel>, cancel_baton=0x0,
pool=0x8095310) at subversion/libsvn_wc/lock.c:664
#6 0xb7ecd28b in do_open (adm_access=0xbfc70438, associated=0x0,
path=0x8073ee0 "", write_lock=0, depth=-1, under_construction=0,
cancel_func=0x805161d <svn_cl__check_cancel>, cancel_baton=0x0,
pool=0x8095310) at subversion/libsvn_wc/lock.c:664
#7 0xb7ece123 in svn_wc_adm_open_anchor (anchor_access=0xbfc70438,
target_access=0xbfc70434, target=0xbfc70430, path=0x8073ee0 "",
write_lock=0, depth=-1, cancel_func=0x805161d <svn_cl__check_cancel>,
cancel_baton=0x0, pool=0x8095310) at subversion/libsvn_wc/lock.c:1119
#8 0xb7f11054 in svn_client_status2 (result_rev=0xbfc704cc,
path=0x8073ee0 "", revision=0xbfc7053c,
status_func=0x8056c79 <print_status>, status_baton=0xbfc70520, recurse=1,
get_all=0, update=0, no_ignore=0, ignore_externals=0, ctx=0x8072690,
pool=0x8095310) at subversion/libsvn_client/status.c:227
#9 0x08056e0c in do_status (opt_state=0xbfc7067c, target=0x8073ee0 "",
rev=0xbfc7053c, status_baton=0xbfc70520, ctx=0x8072690, pool=0x8095310)
at subversion/svn/status-cmd.c:160
#10 0x08057081 in svn_cl__status (os=0x80722c0, baton=0xbfc7066c,
pool=0x80721a8) at subversion/svn/status-cmd.c:241
#11 0x08052fb1 in main (argc=2, argv=0xbfc70824) at subversion/svn/main.c:1485
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Crash with svn 1.4.0
Posted by Lieven Govaerts <sv...@mobsol.be>.
Stefan Küng wrote:
> Chris AtLee wrote:
>> Hello,
>>
>> Sorry if this is a duplicate post, I sent this message yesterday and
>> didn't see it appear in the mailing list archives, so I figured I'd
>> subscribe and try again.
>>
>> I can semi-reliably reproduce a crash with svn 1.4.0 if I interrupt it
>> soon after starting a 'svn status' command. It seems to only crash if I
>> interrupt it before any output has been generated (while it's locking
>> the wc?) My working copy is fairly large (a few hundred megs), so there
>> is often a few seconds before any status information is output. It runs
>> clean under valgrind except for an "Invalid read of size 4" at
>> apr_hash.c:117, which isn't too surprising.
>>
>> Please let me know if there's any other information I can make available
>> to help track this down.
>
> If I may add some comments about this:
> the same crash happens in TortoiseSVN as sent in crashreports
> indicate. From what I could gather from the crashreports so far is
> that the crash happens when the pool gets cleaned up, and only if the
> svn_client_status() call gets interrupted by the cancel callback.
> It happens almost every time if I set the cancel flag even before I
> call svn_client_status() (which means the very first cancel callback
> will stop the function).
> I haven't had the time to look closer at this issue though - I know I
> should have since about 80% of the crashreports coming in for version
> 1.4.0 are about this issue.
>
> Stefan
>
Issue #2623 is created for this problem:
http://subversion.tigris.org/issues/show_bug.cgi?id=2623
Thanks for the detailed report!
Lieven.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Crash with svn 1.4.0
Posted by Stefan Küng <to...@gmail.com>.
Chris AtLee wrote:
> Hello,
>
> Sorry if this is a duplicate post, I sent this message yesterday and
> didn't see it appear in the mailing list archives, so I figured I'd
> subscribe and try again.
>
> I can semi-reliably reproduce a crash with svn 1.4.0 if I interrupt it
> soon after starting a 'svn status' command. It seems to only crash if I
> interrupt it before any output has been generated (while it's locking
> the wc?) My working copy is fairly large (a few hundred megs), so there
> is often a few seconds before any status information is output. It runs
> clean under valgrind except for an "Invalid read of size 4" at
> apr_hash.c:117, which isn't too surprising.
>
> Please let me know if there's any other information I can make available
> to help track this down.
If I may add some comments about this:
the same crash happens in TortoiseSVN as sent in crashreports indicate.
From what I could gather from the crashreports so far is that the crash
happens when the pool gets cleaned up, and only if the
svn_client_status() call gets interrupted by the cancel callback.
It happens almost every time if I set the cancel flag even before I call
svn_client_status() (which means the very first cancel callback will
stop the function).
I haven't had the time to look closer at this issue though - I know I
should have since about 80% of the crashreports coming in for version
1.4.0 are about this issue.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
[PATCH] Crash with svn 1.4.0
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@codematters.co.uk> writes:
> Reverting r19196, the non-recursive closing stuff, stops the crash.
r19196 stopped removing pool cleanup handlers which makes it more
likely batons get closed more than once, it also started to check
svn_wc__adm_access_closed to detect double closes. The combination of
the two reveals that svn_wc__adm_access_closed does not always get
set:
Index: subversion/libsvn_wc/lock.c
===================================================================
--- subversion/libsvn_wc/lock.c (revision 21766)
+++ subversion/libsvn_wc/lock.c (working copy)
@@ -1336,10 +1336,11 @@
SVN_ERR(remove_lock(adm_access->path, adm_access->pool));
adm_access->lock_exists = FALSE;
}
- /* Reset to prevent further use of the write lock. */
- adm_access->type = svn_wc__adm_access_closed;
}
+ /* Reset to prevent further use of the lock. */
+ adm_access->type = svn_wc__adm_access_closed;
+
/* Detach from set */
if (adm_access->set)
{
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Crash with svn 1.4.0
Posted by Philip Martin <ph...@codematters.co.uk>.
"Chris AtLee" <ch...@atlee.ca> writes:
> I can semi-reliably reproduce a crash with svn 1.4.0 if I interrupt it
> soon after starting a 'svn status' command. It seems to only crash if I
> interrupt it before any output has been generated (while it's locking
> the wc?) My working copy is fairly large (a few hundred megs), so there
> is often a few seconds before any status information is output. It runs
> clean under valgrind except for an "Invalid read of size 4" at
> apr_hash.c:117, which isn't too surprising.
I can reproduce this using this patch:
Index: subversion/svn/main.c
===================================================================
--- subversion/svn/main.c (revision 21766)
+++ subversion/svn/main.c (working copy)
@@ -853,7 +853,8 @@
svn_error_t *
svn_cl__check_cancel(void *baton)
{
- if (cancelled)
+ static int dbg = 8;
+ if (cancelled || ! --dbg)
return svn_error_create(SVN_ERR_CANCELLED, NULL, _("Caught signal"));
else
return SVN_NO_ERROR;
and this working copy:
$ rm -rf repo wc
$ svnadmin create repo
$ svn co file://`pwd`/repo wc
$ svn mkdir wc/a wc/a/a wc/a/b
$ svn st wc
../svn/subversion/svn/main.c:858: (apr_err=200015)
svn: Caught signal
Segmentation fault
Reverting r19196, the non-recursive closing stuff, stops the crash.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org