You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Küng <to...@gmail.com> on 2012/05/22 21:31:57 UTC
multiple crashes
Hi,
Our crash reporting tool already gathered a few crashes in the svn
library. 22 reports are already in with access violations in
svn_relpath_join().
those 22 reports are in two crash groups, but from the stack traces
there are four problems that cause these crashes:
https://www.crash-server.com/Problem.aspx?ClientID=tsvn&ProblemID=1056
and
https://www.crash-server.com/Problem.aspx?ClientID=tsvn&ProblemID=1015
contain all the crash dumps (login info was sent to private@ a while ago)
libsvn_tsvn32!svn_relpath_join+0x10
libsvn_tsvn32!svn_wc__internal_get_origin+0x1b2
libsvn_tsvn32!svn_client_commit5+0x14d3
libsvn_tsvn32!svn_client__harvest_committables+0x26a
libsvn_tsvn32!svn_client_commit5+0x2e4
here the 'status' after svn_wc__db_scan_addition() is
svn_wc__db_status_incomplete which might be an indication why
original_repos_relpath is NULL and then causes the access violation in
svn_relpath_join().
**********
libsvn_tsvn32!svn_relpath_join+0x10
libsvn_tsvn32!svn_wc__internal_get_origin+0x1b2
libsvn_tsvn32!svn_client_diff_summarize_dup+0x56c
libsvn_tsvn32!svn_client_export5+0x1bb
no idea why here original_repos_relpath is NULL though. Maybe you have
more luck analyzing that crash dump.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: multiple crashes
Posted by Stefan Küng <to...@gmail.com>.
On Fri, May 25, 2012 at 3:43 PM, Stefan Küng <to...@gmail.com> wrote:
> On 25.05.2012 10:54, Philip Martin wrote:
>>
>> Stefan Küng<to...@gmail.com> writes:
>>
>>> libsvn_tsvn32!svn_relpath_join+0x10
>>> libsvn_tsvn32!svn_wc__internal_get_origin+0x1b2
>>> libsvn_tsvn32!svn_client_commit5+0x14d3
>>> libsvn_tsvn32!svn_client__harvest_committables+0x26a
>>> libsvn_tsvn32!svn_client_commit5+0x2e4
>>>
>>> here the 'status' after svn_wc__db_scan_addition() is
>>> svn_wc__db_status_incomplete which might be an indication why
>>> original_repos_relpath is NULL and then causes the access violation in
>>> svn_relpath_join().
>>
>>
>> One way to get incomplete with status add is to interrupt a wc-to-wc
>> copy. That gives things like:
>>
>> $ svn st wc
>> A + wc/X
>> ! wc/X/B
>> ! wc/X/f
>>
>> But those have original_repos_relpath and the commit doesn't crash.
>>
>> Is there some other way of getting incomplete with add? Perhaps an
>> interrupted merge?
>
>
> No idea how the wc got into this state. As I said: this comes from a crash
> dump. All I can see is the stack trace and some of the variables passed to
> the functions in the stack trace.
count is now up to 46 dumps for this exact crash.
It's now the top crash which hasn't been resolved yet.
Going through the others now, be back soon with other crashes which
happen in the svn library.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: multiple crashes
Posted by Stefan Küng <to...@gmail.com>.
On 25.05.2012 10:54, Philip Martin wrote:
> Stefan Küng<to...@gmail.com> writes:
>
>> libsvn_tsvn32!svn_relpath_join+0x10
>> libsvn_tsvn32!svn_wc__internal_get_origin+0x1b2
>> libsvn_tsvn32!svn_client_commit5+0x14d3
>> libsvn_tsvn32!svn_client__harvest_committables+0x26a
>> libsvn_tsvn32!svn_client_commit5+0x2e4
>>
>> here the 'status' after svn_wc__db_scan_addition() is
>> svn_wc__db_status_incomplete which might be an indication why
>> original_repos_relpath is NULL and then causes the access violation in
>> svn_relpath_join().
>
> One way to get incomplete with status add is to interrupt a wc-to-wc
> copy. That gives things like:
>
> $ svn st wc
> A + wc/X
> ! wc/X/B
> ! wc/X/f
>
> But those have original_repos_relpath and the commit doesn't crash.
>
> Is there some other way of getting incomplete with add? Perhaps an
> interrupted merge?
No idea how the wc got into this state. As I said: this comes from a
crash dump. All I can see is the stack trace and some of the variables
passed to the functions in the stack trace.
>
> The documentation for svn_wc__node_get_origin says that for an added
> node (meaning not copied) the function returns NULL. This indicates
> that callers are probably not going to crash if we return NULL for the
> incomplete case:
>
> svn diff ../src-1.7/subversion/libsvn_wc/node.c
> Index: ../src-1.7/subversion/libsvn_wc/node.c
> ===================================================================
> --- ../src-1.7/subversion/libsvn_wc/node.c (revision 1342275)
> +++ ../src-1.7/subversion/libsvn_wc/node.c (working copy)
> @@ -1407,7 +1407,10 @@
> return SVN_NO_ERROR; /* Local addition */
> }
>
> - *repos_relpath = svn_relpath_join(
> + if (!original_repos_relpath)
> + *repos_relpath = NULL;
> + else
> + *repos_relpath = svn_relpath_join(
> original_repos_relpath,
> svn_dirent_skip_ancestor(op_root_abspath,
> local_abspath),
>
> I'd still like to be able to reproduce it.
>
>>
>> **********
>>
>> libsvn_tsvn32!svn_relpath_join+0x10
>> libsvn_tsvn32!svn_wc__internal_get_origin+0x1b2
>> libsvn_tsvn32!svn_client_diff_summarize_dup+0x56c
>> libsvn_tsvn32!svn_client_export5+0x1bb
>>
>> no idea why here original_repos_relpath is NULL though. Maybe you have
>> more luck analyzing that crash dump.
>
> Does this mean you cannot determine status in the same way you
> determined status above?
Status is 0 here (normal). That's why I don't know how
original_repos_relpath could be NULL.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: multiple crashes
Posted by Philip Martin <ph...@wandisco.com>.
Stefan Küng <to...@gmail.com> writes:
> libsvn_tsvn32!svn_relpath_join+0x10
> libsvn_tsvn32!svn_wc__internal_get_origin+0x1b2
> libsvn_tsvn32!svn_client_commit5+0x14d3
> libsvn_tsvn32!svn_client__harvest_committables+0x26a
> libsvn_tsvn32!svn_client_commit5+0x2e4
>
> here the 'status' after svn_wc__db_scan_addition() is
> svn_wc__db_status_incomplete which might be an indication why
> original_repos_relpath is NULL and then causes the access violation in
> svn_relpath_join().
One way to get incomplete with status add is to interrupt a wc-to-wc
copy. That gives things like:
$ svn st wc
A + wc/X
! wc/X/B
! wc/X/f
But those have original_repos_relpath and the commit doesn't crash.
Is there some other way of getting incomplete with add? Perhaps an
interrupted merge?
The documentation for svn_wc__node_get_origin says that for an added
node (meaning not copied) the function returns NULL. This indicates
that callers are probably not going to crash if we return NULL for the
incomplete case:
svn diff ../src-1.7/subversion/libsvn_wc/node.c
Index: ../src-1.7/subversion/libsvn_wc/node.c
===================================================================
--- ../src-1.7/subversion/libsvn_wc/node.c (revision 1342275)
+++ ../src-1.7/subversion/libsvn_wc/node.c (working copy)
@@ -1407,7 +1407,10 @@
return SVN_NO_ERROR; /* Local addition */
}
- *repos_relpath = svn_relpath_join(
+ if (!original_repos_relpath)
+ *repos_relpath = NULL;
+ else
+ *repos_relpath = svn_relpath_join(
original_repos_relpath,
svn_dirent_skip_ancestor(op_root_abspath,
local_abspath),
I'd still like to be able to reproduce it.
>
> **********
>
> libsvn_tsvn32!svn_relpath_join+0x10
> libsvn_tsvn32!svn_wc__internal_get_origin+0x1b2
> libsvn_tsvn32!svn_client_diff_summarize_dup+0x56c
> libsvn_tsvn32!svn_client_export5+0x1bb
>
> no idea why here original_repos_relpath is NULL though. Maybe you have
> more luck analyzing that crash dump.
Does this mean you cannot determine status in the same way you
determined status above?
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com