Your message dated Tue, 17 Dec 2019 21:33:32 -0500 with message-id <20191218023332.p6lmw2vru5i6pnxx@localhost> and subject line Re: Bug#425414: subversion: segfaults while running diff between two URLs has caused the Debian Bug report #425414, regarding subversion: segfaults while running diff between two URLs to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 425414: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425414 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: subversion Version: 1.4.2dfsg1-2 Severity: important svn runs into a segmentation fault while executing a diff statement that looks like: svn diff --diff-cmd diff-wrapper file:///repo/tags/version-x/foo \ file:///repo/trunk/foo The problem started with the version coming with debian 4.0, the repository was created on the previous debian version. It is not 100% reproducable, it looks like a checkin or some other circumstances make it vanish, but it usually happens again some hours/days later. There is a backtrace for this problem made by someone else under http://anarazel.de/bugreport-svn-segfault.txt so the problem happens on other systems too. I traced svn a little bit and it looks like the hash contains references to dynamically allocated strings which are released via free and accessed afterwards. valgrind suggests this too - find_entry accesses memory which was free'd earlier ==19633== at 0x40CFFD5: find_entry (apr_hash.c:265) ==19633== by 0x40D0224: apr_hash_get (apr_hash.c:330) ==19633== by 0x40B53E6: (within /usr/lib/libsvn_subr-1.so.1.0.0) ==19633== by 0x40B6281: svn_utf_cstring_from_utf8_ex2 (in /usr/lib/libsvn_subr-1.so.1.0.0) ==19633== by 0x40AFC18: svn_stream_printf_from_utf8 (in /usr/lib/libsvn_subr-1.so.1.0.0) ==19633== by 0x403CB83: (within /usr/lib/libsvn_client-1.so.1.0.0) ==19633== by 0x4046C1F: (within /usr/lib/libsvn_client-1.so.1.0.0) ==19633== by 0x4083AA0: (within /usr/lib/libsvn_delta-1.so.1.0.0) ==19633== by 0x425F983: (within /usr/lib/libsvn_repos-1.so.1.0.0) ==19633== by 0x426022D: (within /usr/lib/libsvn_repos-1.so.1.0.0) ==19633== by 0x425FBD4: (within /usr/lib/libsvn_repos-1.so.1.0.0) ==19633== by 0x426022D: (within /usr/lib/libsvn_repos-1.so.1.0.0) ==19633== Address 0x4E61910 is 696 bytes inside a block of size 163,840 free'd ==19633== at 0x401D24F: free (vg_replace_malloc.c:235) ==19633== by 0x40D6EC3: allocator_free (apr_pools.c:371) ==19633== by 0x40D748D: apr_pool_destroy (apr_pools.c:769) ==19633== by 0x42602C8: (within /usr/lib/libsvn_repos-1.so.1.0.0) ==19633== by 0x425FBD4: (within /usr/lib/libsvn_repos-1.so.1.0.0) ==19633== by 0x426022D: (within /usr/lib/libsvn_repos-1.so.1.0.0) ==19633== by 0x425FBD4: (within /usr/lib/libsvn_repos-1.so.1.0.0) ==19633== by 0x426022D: (within /usr/lib/libsvn_repos-1.so.1.0.0) ==19633== by 0x425FBD4: (within /usr/lib/libsvn_repos-1.so.1.0.0) ==19633== by 0x426022D: (within /usr/lib/libsvn_repos-1.so.1.0.0) ==19633== by 0x425FBD4: (within /usr/lib/libsvn_repos-1.so.1.0.0) ==19633== by 0x426022D: (within /usr/lib/libsvn_repos-1.so.1.0.0) The error happens at a point where the hash function compares the keys (line numbers may be slightly off since I have added some debug printf statements): Program received signal SIGSEGV, Segmentation fault. 0xb7e62116 in find_entry (ht=0x806e960, key=0x84f0ea8, klen=46, val=0x0) at ../tables/apr_hash.c:283 283 if (he->hash == hash) 284 && he->klen == klen 285 && memcmp(he->key, key, klen) == 0) 286 break; 287 } I have tried to verify this by setting a break point to unmap and look at the arguments of allocator_free() and as far as I understand it a pool containing the key "svn-utf-UTF-8toAPR_LOCALE_CHARSET-xlate-handle" is released (and unmapped) and after that find_entry tries to reference the location which was just unmapped: Breakpoint 3, 0xb7dd63e0 in munmap () from /lib/tls/libc.so.6 (gdb) bt #0 0xb7dd63e0 in munmap () from /lib/tls/libc.so.6 #1 0xb7d73a3c in free () from /lib/tls/libc.so.6 #2 0xb7e69064 in allocator_free (allocator=0x8070918, node=0xb72fd008) at ../memory/unix/apr_pools.c:371 ^^^^^^^^^^ # release memory at address 0xb72fd008 #3 0xb7e6962e in apr_pool_destroy (pool=0xb72fd020) at ../memory/unix/apr_pools.c:769 #13 0xb7ce2770 in svn_repos_finish_report () from /usr/lib/libsvn_repos-1.so.1 #19 0xb7ebb6d0 in svn_ra_do_status () from /usr/lib/libsvn_ra-1.so.1 #20 0xb7f03ca9 in svn_client_diff_summarize () #21 0xb7f04118 in svn_client_diff3 () from /usr/lib/libsvn_client-1.so.1 find_entry tries to access the following keys: 0x8283680, 0x82c76d8, 0x829b6c8, 0xb72fd2c0, and segfaults when accessing 0xb72fd2c0 regards, Jean -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.20.7n Locale: LANG=de_DE@euro, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15) Versions of packages subversion depends on: ii libapr1 1.2.7-8.2 The Apache Portable Runtime Librar ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libsvn1 1.4.2dfsg1-2 Shared libraries used by Subversio subversion recommends no packages. -- no debconf information
--- End Message ---
--- Begin Message ---On Mon, May 21, 2007 at 05:01:39PM +0200, Jean Wolter wrote: > svn runs into a segmentation fault while executing a diff statement that > looks like: > > svn diff --diff-cmd diff-wrapper file:///repo/tags/version-x/foo \ > file:///repo/trunk/foo > > The problem started with the version coming with debian 4.0, the repository > was created on the previous debian version. It is not 100% reproducable, > it looks like a checkin or some other circumstances make it vanish, but it > usually happens again some hours/days later. There have been various fixes around use of the hash APIs in svn since 1.4.2. I'm going to close this bug. Please reopen if you can still reproduce it. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
--- End Message ---
