You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Evgeny Kotkov <ev...@visualsvn.com> on 2014/12/30 17:47:04 UTC

Re: svn commit: r1648542 - /subversion/trunk/subversion/libsvn_fs_fs/tree.c

Stefan Fuhrmann <st...@apache.org> writes:

> URL: http://svn.apache.org/r1648542
> Log:
> In FSFS, remove the L1 DAG cache locking parameters.

[...]

As of this revision, I am also seeing random Apache HTTPD Server segfaults.
I tested two Subversion 1.9.0-dev builds from r1648532 and r1648542.  I could
not reproduce the crashes with the first build, but the second one *does* crash
occasionally.  Here is a sample backtrace:

  libsvn_fs-1.dll!get_node_revision_body(..., fs=0x0000000, ...)
  libsvn_fs-1.dll!svn_fs_fs__get_node_revision()
  libsvn_fs-1.dll!get_node_revision()
  libsvn_fs-1.dll!svn_fs_fs__dag_get_node()
  libsvn_fs-1.dll!svn_fs_fs__dag_open()
  libsvn_fs-1.dll!open_path()
  libsvn_fs-1.dll!history_prev()
  libsvn_fs-1.dll!fs_history_prev()
  libsvn_fs-1.dll!svn_fs_history_prev2()
  mod_dav_svn.so!get_last_history_rev()
  mod_dav_svn.so!dav_svn__get_safe_cr()
  mod_dav_svn.so!send_vsn_url()
  mod_dav_svn.so!add_helper()
  mod_dav_svn.so!upd_add_file()
  libsvn_repos-1.dll!add_file_smartly()
  libsvn_repos-1.dll!update_entry()
  libsvn_repos-1.dll!delta_dirs()
  libsvn_repos-1.dll!update_entry()
  libsvn_repos-1.dll!delta_dirs()
  libsvn_repos-1.dll!update_entry()
  libsvn_repos-1.dll!delta_dirs()
  libsvn_repos-1.dll!update_entry()
  libsvn_repos-1.dll!delta_dirs()
  (...)
  libsvn_repos-1.dll!delta_dirs()
  libsvn_repos-1.dll!update_entry()
  libsvn_repos-1.dll!delta_dirs()
  libsvn_repos-1.dll!update_entry()
  libsvn_repos-1.dll!delta_dirs()
  libsvn_repos-1.dll!drive()
  libsvn_repos-1.dll!finish_report()
  libsvn_repos-1.dll!svn_repos_finish_report()
  mod_dav_svn.so!dav_svn__update_report()
  mod_dav_svn.so!deliver_report()
  mod_dav.so!dav_method_report()
  ...


Regards,
Evgeny Kotkov

Re: svn commit: r1648542 - /subversion/trunk/subversion/libsvn_fs_fs/tree.c

Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Tue, Dec 30, 2014 at 5:47 PM, Evgeny Kotkov <ev...@visualsvn.com>
wrote:

> Stefan Fuhrmann <st...@apache.org> writes:
>
> > URL: http://svn.apache.org/r1648542
> > Log:
> > In FSFS, remove the L1 DAG cache locking parameters.
>
> [...]
>
> As of this revision, I am also seeing random Apache HTTPD Server segfaults.
> I tested two Subversion 1.9.0-dev builds from r1648532 and r1648542.  I
> could
> not reproduce the crashes with the first build, but the second one *does*
> crash
> occasionally.  Here is a sample backtrace:
>

I get it to crash somewhat reproducibly now by setting MaxMemFree=4
and SVN_ALLOCATOR_RECOMMENDED_MAX_FREE to 4096.

Then release builds of mod_dav_svn and svnserve will segfault on
svn diff --summarize -r0:300000 $ApacheRepo. It does not segfault
in debug build, though. Continue investigation ...

-- Stefan^2.

Re: svn commit: r1648542 - /subversion/trunk/subversion/libsvn_fs_fs/tree.c

Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Wed, Dec 31, 2014 at 12:48 AM, Bert Huijben <be...@qqmail.nl> wrote:

> Any idea what causes this difference?
>

Yep, found it. The OS came with a 1.7.9 client.
Using a /trunk client, we are down to ~4min.

Most of that 3 min overhead seems to be HTTP processing
(the client CPU is much busier than against svnserve)
but I haven't actually measured it.


>  Is it all in the security walk?
>
>
>
> The diff --summarize should result in a single report from server to
> client, without additional get requests for data
>
> (except for the one time ra session setup, revision lookup, etc. at the
> start)
>

Well, 1.7.9 seems to behave differently: 3..4min
of server-side processing with no output on the
client console, followed (slowly) sending data to
the client for display. No actual delta seems to
be transferred as the total amount of data is
about the same as with /trunk.

-- Stefan^2.


>
>
> *From:* Stefan Fuhrmann [mailto:stefan.fuhrmann@wandisco.com]
> *Sent:* woensdag 31 december 2014 00:11
> *To:* Evgeny Kotkov
> *Cc:* Stefan Fuhrman; Subversion Development
> *Subject:* Re: svn commit: r1648542 -
> /subversion/trunk/subversion/libsvn_fs_fs/tree.c
>
>
>
> On Tue, Dec 30, 2014 at 5:47 PM, Evgeny Kotkov <
> evgeny.kotkov@visualsvn.com> wrote:
>
> Stefan Fuhrmann <st...@apache.org> writes:
>
> > URL: http://svn.apache.org/r1648542
> > Log:
> > In FSFS, remove the L1 DAG cache locking parameters.
>
> [...]
>
> As of this revision, I am also seeing random Apache HTTPD Server segfaults.
> I tested two Subversion 1.9.0-dev builds from r1648532 and r1648542.  I
> could
> not reproduce the crashes with the first build, but the second one *does*
> crash
> occasionally.  Here is a sample backtrace:
>
>
> [...]
>
> Should be fixed with r1648612.
>
> Interesting observation: svnserve completes the test case in 1 minute
>
> while mod_dav_svn eats a whopping 30 CPU minutes. Everything with
>
> default settings on a format 7 repo with deltified directories.
>
>
>
> -- Stefan^2.
>
>
>

RE: svn commit: r1648542 - /subversion/trunk/subversion/libsvn_fs_fs/tree.c

Posted by Bert Huijben <be...@qqmail.nl>.
Any idea what causes this difference?

 

Is it all in the security walk?

 

The diff --summarize should result in a single report from server to client, without additional get requests for data

(except for the one time ra session setup, revision lookup, etc. at the start)

 

                Bert

 

From: Stefan Fuhrmann [mailto:stefan.fuhrmann@wandisco.com] 
Sent: woensdag 31 december 2014 00:11
To: Evgeny Kotkov
Cc: Stefan Fuhrman; Subversion Development
Subject: Re: svn commit: r1648542 - /subversion/trunk/subversion/libsvn_fs_fs/tree.c

 

On Tue, Dec 30, 2014 at 5:47 PM, Evgeny Kotkov <evgeny.kotkov@visualsvn.com <ma...@visualsvn.com> > wrote:

Stefan Fuhrmann <stefan2@apache.org <ma...@apache.org> > writes:

> URL: http://svn.apache.org/r1648542
> Log:
> In FSFS, remove the L1 DAG cache locking parameters.

[...]

As of this revision, I am also seeing random Apache HTTPD Server segfaults.
I tested two Subversion 1.9.0-dev builds from r1648532 and r1648542.  I could
not reproduce the crashes with the first build, but the second one *does* crash
occasionally.  Here is a sample backtrace:


[...]

Should be fixed with r1648612.

Interesting observation: svnserve completes the test case in 1 minute

while mod_dav_svn eats a whopping 30 CPU minutes. Everything with

default settings on a format 7 repo with deltified directories.

 

-- Stefan^2.

 


Re: svn commit: r1648542 - /subversion/trunk/subversion/libsvn_fs_fs/tree.c

Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Tue, Dec 30, 2014 at 5:47 PM, Evgeny Kotkov <ev...@visualsvn.com>
wrote:

> Stefan Fuhrmann <st...@apache.org> writes:
>
> > URL: http://svn.apache.org/r1648542
> > Log:
> > In FSFS, remove the L1 DAG cache locking parameters.
>
> [...]
>
> As of this revision, I am also seeing random Apache HTTPD Server segfaults.
> I tested two Subversion 1.9.0-dev builds from r1648532 and r1648542.  I
> could
> not reproduce the crashes with the first build, but the second one *does*
> crash
> occasionally.  Here is a sample backtrace:
>

[...]

Should be fixed with r1648612.

Interesting observation: svnserve completes the test case in 1 minute
while mod_dav_svn eats a whopping 30 CPU minutes. Everything with
default settings on a format 7 repo with deltified directories.

-- Stefan^2.