Daniel Shahaf wrote on Wed, Jul 17, 2013 at 08:05:41 +0300:
> Michael Pruemm wrote on Tue, Jul 09, 2013 at 16:00:38 +0200:
> > On Tue, Jul 9, 2013 at 3:44 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> >
> > > Michael, does this only happen with ra_serf? Can you please test
> > > with svn://, or svn+ssh://, or file:// access?
> > >
> >
> > Here are the results with 32-bit 1.8.0 using svn+ssh:
> >
> > LANG=$l1 time svn co svn+ssh://... -r244060 C8-32-$l1-svnssh
> > 17.71user 11.13system 1:05.59elapsed 43%CPU (0avgtext+0avgdata
> > 325792maxresident)k
> > 4920inputs+1764088outputs (29major+51815minor)pagefaults 0swaps
> >
> >
> > LANG=$l2 time svn co svn+ssh://... -r244060 C8-32-$l2-svnssh
> > (core dump)
> > 11.71user 10.44system 1:13.20elapsed 30%CPU (0avgtext+0avgdata
> > 3554080maxresident)k
> > 1784inputs+3064200outputs (13major+223537minor)pagefaults 0swaps
> >
> > Note: instead of the error message I got a core dump. That happened before,
> > too. The check-out went about as far as in the other failing cases.
>
> I suspect the core dump is http://svn.apache.org/r1503318 --- do you get
> further if you apply that and rebuild svn?
If that's true, it would manifest as SIGABRT. If the reason as out of
memory I think you'd get a different signal. (So looking at the signal
sent will let you rule out the r1503318 theory)
Received on 2013-07-17 07:22:07 CEST