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 <s...@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)
