On 7/21/06, Bohlen, Olaf <Olaf.Bohlen@ewe.de> wrote:
> Hi,
>
> we are currently deploying SVN 1.3.2 in production. Since we need to check-in large files (>2GB) we had trouble with SVN and the normal APR 0.9.7.
> Our platform looks like following:
> - Solaris 10 on UltraSPARC
> - Apache 2.2.2
> - SVN 1.3.2
> - APR 1.2.7
> - APR Util 1.2.7
>
> All was compiled using gcc in 32bit mode. We can now check in and out large files, but when doing svn status apache child processes segfault:
>
> -- error_log --
> [Fri Jul 21 12:41:03 2006] [notice] child pid 22779 exit signal Segmentation fault (11)
> [Fri Jul 21 12:41:03 2006] [notice] child pid 22781 exit signal Segmentation fault (11)
> -- EOF --
>
> According to the access log follwing request lead to the SEGV:
>
> -- access_log --
> 1.2.3.4 - - [21/Jul/2006:12:41:02 +0200] "PROPFIND /subversion/foo/foo/trunk HTTP/1.1" 401 554
> -- EOF --
>
> A truss output looks like this:
>
> -- truss.out --
> 18855: open("/dev/urandom", O_RDONLY) = 18
> 18855: fstat(18, 0xFFBFEBA8) = 0
> 18855: read(18, 0xFFBFEB90, 20) = 20
> 18855: EDBFD3 &F2 " zAF1DE9 jDE84E28BDC ~ sDD\r
> 18855: close(18) = 0
> 18855: getpid() = 18855 [3063]
> 18855: time() = 1153476650
> 18855: time() = 1153476650
> 18855: time() = 1153476650
> 18855: time() = 1153476650
> 18855: time() = 1153476650
> 18855: time() = 1153476650
> 18855: time() = 1153476650
> 18855: Incurred fault #6, FLTBOUNDS %pc = 0xFEBE7C04
> 18855: siginfo: SIGSEGV SEGV_MAPERR addr=0x00004D5C
> 18855: Received signal #11, SIGSEGV [caught]
> 18855: siginfo: SIGSEGV SEGV_MAPERR addr=0x00004D5C
> 18855: schedctl() = 0xFE6EA000
> 18855: lwp_sigmask(SIG_SETMASK, 0x00000400, 0x00000000) = 0xFFBFFEFF [0x0000FFFF]
> 18855: chdir("/usr/local/apache2.2.2") = 0
> 18855: sigaction(SIGSEGV, 0xFFBFE860, 0xFFBFE900) = 0
> 18855: getpid() = 18855 [3063]
> 18855: getpid() = 18855 [3063]
> 18855: kill(18855, SIGSEGV) = 0
> 18855: setcontext(0xFFBFE860)
> 18855: Received signal #11, SIGSEGV [default]
> 18855: siginfo: SIGSEGV pid=18855 uid=5104
>
> -- EOF --
>
> I found the same problem on google:
> http://developer.spikesource.com/forums/viewtopic.php?p=1643
>
> This user has exactly the same problem. But we cannot use BDB as backend, since we use an NFS file share as repository base and you recommend FSFS for NFS file systems.
>
> I really need your help guys!
Without a backtrace it's really hard for us to do much of anything
here. Any chance you can use gdb to get one for us?
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 21 18:27:06 2006