[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#719791: marked as done (libapr1: Crash in libapr when using svn+ssh URL in svn:externals)

Your message dated Sat, 21 Sep 2013 23:33:05 +0200
with message-id <12901409.q6mG4au2WF@k>
and subject line Re: Bug#719791: Problem has gone since new subversion package version
has caused the Debian Bug report #719791,
regarding libapr1: Crash in libapr when using svn+ssh URL in svn:externals
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 owner@bugs.debian.org
immediately.)


-- 
719791: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719791
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: libapr1
Version: 1.4.8-1
Severity: normal
Tags: upstream

Dear Maintainer,

   * What led up to the situation?

I am using a svn+ssh URL in the svn:externals property to map in a directory from another repository:

$ svn pg svn:externals . 
trunk     svn+ssh://user@host.org/svnroot/repos/trunk/

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

Now I want to run svn up so the external is checked out

   * What was the outcome of this action?

svn up fails with this message: 

$ LANG=C svn up 
svn: warning: Error handling externals definition for 'trunk':
svn: warning: To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file.


   * What outcome did you expect instead?

svn up should check out the external repository into directory trunk


   * Things I tried:

I tried also without the user@ in the URL, placing the user information in my .ssh/config, same result.

Same behaviour on Ubuntu

Interestingly, on Scientific Linux release 6.2 it works it ~/.ssh/config does NOT exist. Otherwise, same error. That's why I suspect the error is upstream.

Using gdb I found that a child process segfaults, in the function run_child_cleanups, and this failure seems to be the cause of the message

I installed the package libapr1-dbg to get debugging symbols, then the backtrace in gdb looks like this:


$ LANG=C gdb svn
GNU gdb (GDB) 7.6 (Debian 7.6-5)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/svn...(no debugging symbols found)...done.
(gdb) set follow-fork-mode child
(gdb) r up 
Starting program: /usr/bin/svn up
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New process 25454]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7fbc780 (LWP 25454)]
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007ffff6ec2eee in run_child_cleanups (cref=0x7ffff7fec048) at ../memory/unix/apr_pools.c:2365
#2  cleanup_pool_for_exec (p=p@entry=0x7ffff7fec028) at ../memory/unix/apr_pools.c:2372
#3  0x00007ffff6ec2f08 in cleanup_pool_for_exec (p=0x7ffff7fec028) at ../memory/unix/apr_pools.c:2375
#4  0x00007ffff6ec500c in apr_pool_cleanup_for_exec () at ../memory/unix/apr_pools.c:2380
#5  0x00007ffff6ecdb94 in apr_proc_create (new=<optimized out>, progname=0x7ffff7f4c1e0 "ssh", args=0x7ffff7f4c210, env=0x7fffffffd4c0, attr=0x7ffff7f4e1c8, pool=0x7ffff7f4e028) at ../threadproc/unix/proc.c:425
#6  0x00007ffff5a0ff45 in ?? () from /usr/lib/x86_64-linux-gnu/libsvn_ra_svn-1.so.1
#7  0x00007ffff5a12ad1 in ?? () from /usr/lib/x86_64-linux-gnu/libsvn_ra_svn-1.so.1
#8  0x00007ffff7748542 in svn_ra_open3 () from /usr/lib/x86_64-linux-gnu/libsvn_ra-1.so.1
#9  0x00007ffff7bcb084 in svn_client__open_ra_session_internal () from /usr/lib/x86_64-linux-gnu/libsvn_client-1.so.1
#10 0x00007ffff7bcbdda in svn_client__ra_session_from_path () from /usr/lib/x86_64-linux-gnu/libsvn_client-1.so.1
#11 0x00007ffff7bbbd23 in ?? () from /usr/lib/x86_64-linux-gnu/libsvn_client-1.so.1
#12 0x00007ffff7bbc91e in ?? () from /usr/lib/x86_64-linux-gnu/libsvn_client-1.so.1
#13 0x00007ffff70f57d3 in svn_hash_diff () from /usr/lib/x86_64-linux-gnu/libsvn_subr-1.so.1
#14 0x00007ffff7bbcb2d in svn_client__handle_externals () from /usr/lib/x86_64-linux-gnu/libsvn_client-1.so.1
#15 0x00007ffff7bd08be in svn_client__update_internal () from /usr/lib/x86_64-linux-gnu/libsvn_client-1.so.1
#16 0x00007ffff7bd09be in svn_client_update3 () from /usr/lib/x86_64-linux-gnu/libsvn_client-1.so.1
#17 0x0000000000414297 in ?? ()
#18 0x0000000000406bfb in ?? ()
#19 0x00007ffff6904995 in __libc_start_main (main=0x4052a0, argc=2, ubp_av=0x7fffffffe2d8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe2c8) at libc-start.c:260
#20 0x00000000004071a1 in ?? ()
(gdb) quit
A debugging session is active.

        Inferior 2 [process 25454] will be killed.

Quit anyway? (y or n) y
svn: warning: Error handling externals definition for 'trunk':
svn: warning: To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file.


Best regards
Johannes


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.10-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libapr1 depends on:
ii  libc6     2.17-92
ii  libuuid1  2.20.1-5.5

libapr1 recommends no packages.

libapr1 suggests no packages.

-- no debconf information

--- End Message ---
--- Begin Message --- 
Am Freitag, 13. September 2013, 13:56:24 schrieb Johannes Willkomm:
> this problem has dissapeared for me since the subversion package was
> updated to 1.7.9-1+nmu4

Thanks for the follow-up. I am closing this report, then.

--- End Message ---
Reply to: