Bug#348327: subversion segfaults on checkout of more than 10 deep directory
--- Bye, | Phone: (972)-2-6795364 Arieh | Fax: (972)-2-6796453 Since I still can't reproduce this (nor can fellow team member Guilherme), I'd appreciate if you can somehow figure out the relevant difference between your two machines - whether it really is the kernel version, or something else. It seems quite unlikely to me that a kernel version would affect this type of application crash. Meanwhile, I'll try to arrange a test with kernel 2.4.27. I took another computer arieh-3, with 2.4.18-1-k7. And the testcase worked. So whatever it is seems to be in the repository access backends rather than the working copy frontend. You can probably verify this with 'svn diff -r0:HEAD file://$HOME/test.svn' or similar, on the server. (That deals purely in the repository access backends.) Also, just to satisfy my curiosity, can you try this with file:///? Also crashes (I downgraded back to the 1.2.3dfsg1-3). I'm confused - I asked about two different tests - did they both fail? First, the 'svn diff', and second, using subversion 1.2.3 with libsvn0 1.3.0. svn diff -r0:HEAD file://$HOME/test.svn Segmentation fault // Package subversion remains of version 1.2.3dfsg1-3. apt-get install libsvn0=1.3.0-1 ... Preparing to replace libsvn0 1.2.3dfsg1-3 (using .../libsvn0_1.3.0-1_i386.deb) ... ... svn diff -r0:HEAD file://$HOME/test.svn Index: 1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/test.txt === --- 1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/test.txt(revision 0) +++ 1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/test.txt(revision 1) @@ -0,0 +1 @@ +hello I downgraded back, and again got Segmentation Fault. So, looks as the problem is in libsvn0 1.2.3dfsg1-3 on this particular computer (arieh-1). On other computer (arieh-2) with the same version (I even compared md5sums) it works. The computers have different filesystems (reiserfs and ext3), but computer (arieh-3) has ext3 (under 2.4.18). To my sorrow, I don't have another computer, similar to arieh-1 with kernel 2.4.27 and ext3 filesystem. -- Arieh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348327: subversion segfaults on checkout of more than 10 deep directory
Package: subversion Version: 1.2.3dfsg1-3 This time the segfault is not related to locale (as previous ones). From my observations it is related to directory depths. Use following commands sequence to reproduce the problem: mkdir test cd test svnadmin create ~/test.svn svn checkout file:///home/$USER/test.svn/ cd test.svn mkdir -p 1/2/3/4/5/6/7/8/9/10/11/12/13/14/15 echo hello 1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/test.txt svn add 1 svn commit cd .. rm -rf test.svn # ok, repository is ready. Now try to check it out: svn checkout file:///home/$USER/test.svn/ # and here we get the segfault: ~/test$ svn checkout file:///home/$USER/test.svn/ Atest.svn/1 Atest.svn/1/2 Atest.svn/1/2/3 Atest.svn/1/2/3/4 Atest.svn/1/2/3/4/5 Atest.svn/1/2/3/4/5/6 Atest.svn/1/2/3/4/5/6/7 Atest.svn/1/2/3/4/5/6/7/8 Atest.svn/1/2/3/4/5/6/7/8/9 Atest.svn/1/2/3/4/5/6/7/8/9/10 Segmentation fault ~/test$ -- --- Bye, | Phone: (972)-2-6795364 Arieh | Fax: (972)-2-6796453 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348327: subversion segfaults on checkout of more than 10 deep directory
[Skliarouk Arieh] This time the segfault is not related to locale (as previous ones). From my observations it is related to directory depths. Thank you for the precise reproduction recipe! Unfortunately, I was unable to reproduce this - either with the 1.2.3dfsg1-3 or with the 1.3.0-1 in experimental. All steps completed without errors. I'm not sure where to begin in tracking this down. Which CPU architecture is your machine? What version of libapr0 do you have? Also, if you can try subversion 1.3.0-1 from experimental (which requires libneon25, also in experimental), that would be great. Thanks, Peter signature.asc Description: Digital signature
Bug#348327: subversion segfaults on checkout of more than 10 deep directory
Thank you for the precise reproduction recipe! Unfortunately, I was unable to reproduce this - either with the 1.2.3dfsg1-3 or with the 1.3.0-1 in experimental. All steps completed without errors. I'm not sure where to begin in tracking this down. Which CPU architecture is your machine? What version of libapr0 do you have? libapr0 2.0.55-3 libc6 2.3.5-6 libdb4.3 4.3.28-3 libxml2 2.6.22-1 zlib1g 1.2.3-4 Also, if you can try subversion 1.3.0-1 from experimental (which requires libneon25, also in experimental), that would be great. I tried the subversion 1.3.0-1 from experimental, and it worked without errors. One more hint to this puzzle: Before the upgrade, whenever I tried to do remote checkout over ssh (svn co svn+ssh://[EMAIL PROTECTED]/svnroot/blahblah), from client machine with subversion 1.2.3dfsg1-3, it also failed. After the upgrade (on the server) it works, so the bug seemingly sits at the server side code. IMHO, it worthwhile to track the bug, even if it is not seen in latests release. Besides potential buffer overrun, SVN is too important for allow bugs to leave by themselves. # ldd `which svn` libsvn_client-1.so.0 = /usr/lib/libsvn_client-1.so.0 (0x40029000) libsvn_wc-1.so.0 = /usr/lib/libsvn_wc-1.so.0 (0x4004b000) libsvn_ra-1.so.0 = /usr/lib/libsvn_ra-1.so.0 (0x40071000) libsvn_delta-1.so.0 = /usr/lib/libsvn_delta-1.so.0 (0x40075000) libsvn_subr-1.so.0 = /usr/lib/libsvn_subr-1.so.0 (0x4007d000) libapr-0.so.0 = /usr/lib/libapr-0.so.0 (0x400a3000) libpthread.so.0 = /lib/libpthread.so.0 (0x400c4000) libc.so.6 = /lib/libc.so.6 (0x40117000) libsvn_diff-1.so.0 = /usr/lib/libsvn_diff-1.so.0 (0x40231000) libaprutil-0.so.0 = /usr/lib/libaprutil-0.so.0 (0x40237000) libsvn_ra_local-1.so.0 = /usr/lib/libsvn_ra_local-1.so.0 (0x4024d000) libsvn_repos-1.so.0 = /usr/lib/libsvn_repos-1.so.0 (0x40253000) libsvn_fs-1.so.0 = /usr/lib/libsvn_fs-1.so.0 (0x4026e000) libsvn_ra_svn-1.so.0 = /usr/lib/libsvn_ra_svn-1.so.0 (0x40273000) libsvn_ra_dav-1.so.0 = /usr/lib/libsvn_ra_dav-1.so.0 (0x40283000) libdb-4.3.so = /usr/lib/libdb-4.3.so (0x40299000) libexpat.so.1 = /usr/lib/libexpat.so.1 (0x40378000) librt.so.1 = /lib/librt.so.1 (0x40398000) libm.so.6 = /lib/libm.so.6 (0x403ab000) libcrypt.so.1 = /lib/libcrypt.so.1 (0x403d) libnsl.so.1 = /lib/libnsl.so.1 (0x403fe000) libdl.so.2 = /lib/libdl.so.2 (0x40412000) /lib/ld-linux.so.2 (0x4000) libsvn_fs_fs-1.so.0 = /usr/lib/libsvn_fs_fs-1.so.0 (0x40417000) libsvn_fs_base-1.so.0 = /usr/lib/libsvn_fs_base-1.so.0 (0x4042f000) libneon.so.25 = /usr/lib/libneon.so.25 (0x40451000) libssl.so.0.9.7 = /usr/lib/i686/cmov/libssl.so.0.9.7 (0x40469000) libcrypto.so.0.9.7 = /usr/lib/i686/cmov/libcrypto.so.0.9.7 (0x4049b000) libxml2.so.2 = /usr/lib/libxml2.so.2 (0x4059d000) libz.so.1 = /usr/lib/libz.so.1 (0x406ab000) - Arieh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348327: subversion segfaults on checkout of more than 10 deep directory
[Skliarouk Arieh] libapr0 2.0.55-3 libc6 2.3.5-6 libdb4.3 4.3.28-3 libxml2 2.6.22-1 zlib1g 1.2.3-4 Thanks - I'm running the same of everything except libc6 2.3.5-8.1, but that really doesn't seem likely to be the problem. I still can't reproduce the problem. I tried nesting 30 directories with much longer names. Before you upgraded to subversion 1.3.0, I imagine you had matching versions of subversion and libsvn0 - true? (The dependencies don't *quite* enforce this.) Also, I'd still like to know your processor architecture. I'm running i386, which is very forgiving of certain data errors. Architectures such as sparc and alpha are much less so. One more hint to this puzzle: Before the upgrade, whenever I tried to do remote checkout over ssh (svn co svn+ssh://[EMAIL PROTECTED]/svnroot/blahblah), from client machine with subversion 1.2.3dfsg1-3, it also failed. Not surprising - most of the same code paths are exercised. After the upgrade (on the server) it works, so the bug seemingly sits at the server side code. So whatever it is seems to be in the repository access backends rather than the working copy frontend. You can probably verify this with 'svn diff -r0:HEAD file://$HOME/test.svn' or similar, on the server. (That deals purely in the repository access backends.) Also, just to satisfy my curiosity, can you try this with file:///? subversion 1.2.3dfsg1-3 libsvn0 1.3.0-1 This should work fine, as the bug is probably in libsvn0. IMHO, it worthwhile to track the bug, even if it is not seen in latests release. Besides potential buffer overrun, SVN is too important for allow bugs to leave by themselves. Right. Thanks for working with me, Peter signature.asc Description: Digital signature
Bug#348327: subversion segfaults on checkout of more than 10 deep directory
[Skliarouk Arieh] Yes, the version of subversion and libsvn0 were 1.2.3dfsg1-3 For some reason package subversion-tools was REMOVEd and not upgraded. Does it matter? No, doesn't matter. $ uname -a Linux desktop 2.4.27-1-386 #1 Fri Sep 3 06:24:46 UTC 2004 i686 GNU/Linux I installed the subversion version 1.2.3dfsg1-3 on another computer (with 2.6.12-1) and it the svn checkout works. They both seem to have the same packages. Since I still can't reproduce this (nor can fellow team member Guilherme), I'd appreciate if you can somehow figure out the relevant difference between your two machines - whether it really is the kernel version, or something else. It seems quite unlikely to me that a kernel version would affect this type of application crash. Meanwhile, I'll try to arrange a test with kernel 2.4.27. So whatever it is seems to be in the repository access backends rather than the working copy frontend. You can probably verify this with 'svn diff -r0:HEAD file://$HOME/test.svn' or similar, on the server. (That deals purely in the repository access backends.) Also, just to satisfy my curiosity, can you try this with file:///? Also crashes (I downgraded back to the 1.2.3dfsg1-3). I'm confused - I asked about two different tests - did they both fail? First, the 'svn diff', and second, using subversion 1.2.3 with libsvn0 1.3.0. Find attached strace of the crashing svn. Thanks. I don't see anything obviously wrong in the strace output, though. Thanks! Peter signature.asc Description: Digital signature
