On 6/18/07, Dan Christian <dchristian@google.com> wrote:
> I've been trying to test subversion+serf using mstone
> (http://sourceforge.net/projects/mstone). I last updated
> subversion at r25382 (Date: 2007-06-12 15:52:07) and serf at r1111 (Date:
> 2007-06-11 15:25:43).
C-Mike commited some fixes for ra_serf after r25382 - so it might be
worth updating. *shrug*
> I'm getting lots of core dumps with serf. In fact, I can't get through a
> 20min run without a problem. When I run with neon the number of problems is
> much lower (but not 0).
Hmm.
mstone is using threads, right? So, there could be some thread-safety
issues here...
> I've attached the stack traces from a series of runs. There are 112 unique
> stack traces (duplicates were filtered out). Any addresses have been
> replaced by "0x?" to make it possible to filter duplicates.
>
> I'm still working on ways to collect core dump information in a more
> meaningful way (suggestions welcome). Until then I just hoping to start
> some discussion on how the situation could be improved.
Not directly related - but I managed to get valgrind running on an
Ubuntu box over the weekend with a ra_serf build. Current trunk of
SVN and serf showed no leaks or other corruption from within
ra_serf/Subversion code as I tried update/checkout, commit, import,
log, etc. The only problems that valgrind showed were within the
Linux dlopen() calls or within OpenSSL not freeing space - neither of
which serf or Subversion can do much about. So, I'm not sure if that
means that your earlier corruption problems as seen by valgrind are
fixed or if that means I just can't reproduce. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 19 02:05:42 2007