Your message dated Sun, 07 Jun 2009 09:50:46 +0200
with message-id <[email protected]>
and subject line Re: Bug#522159: Maybe old version problem
has caused the Debian Bug report #522159,
regarding subcommander: Core dump after clicking on default trunk branch or
tags tree items after adding a new URL
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.)
--
522159: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522159
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: subcommander
Version: 1.2.2-1
Severity: normal
Start subcommander for first time after install
Add a new URL using Projects | New Repository main menu
Then, selecting the new repo under the root works OK
Then, clicking on tags, branches or trunk under the root causes a core dump
Stack trace:
gdb `which subcommander` core.1234
(gdb) bt
#0 0x00007fba8a7182cb in ?? () from /usr/lib/libneon.so.26
#1 0x00007fba8a71debf in ?? () from /usr/lib/libneon.so.26
#2 0x00007fba8a71df72 in ne_add_server_auth () from /usr/lib/libneon.so.26
#3 0x00007fba8bead9bc in ?? () from /usr/lib/libsvn_ra_dav-1.so.1
#4 0x00007fba8c712824 in svn_ra_open3 () from /usr/lib/libsvn_ra-1.so.1
#5 0x00007fba8cb87c67 in svn_client__open_ra_session_internal () from
/usr/lib/libsvn_client-1.so.1
#6 0x00007fba8cb883b4 in svn_client__ra_session_from_path () from
/usr/lib/libsvn_client-1.so.1
#7 0x00007fba8cb7543e in svn_client_info2 () from /usr/lib/libsvn_client-1.so.1
#8 0x00007fba8cb75c43 in svn_client_info () from /usr/lib/libsvn_client-1.so.1
#9 0x00000000004f32bb in ?? ()
#10 0x00000000004d8849 in ?? ()
#11 0x00000000004dc423 in ?? ()
#12 0x00000000004aabe9 in ?? ()
#13 0x00007fba8da45171 in ?? () from /usr/lib/libapr-1.so.0
#14 0x00007fba8d1c3fc7 in start_thread () from /lib/libpthread.so.0
#15 0x00007fba8a9fd5ad in clone () from /lib/libc.so.6
#16 0x0000000000000000 in ?? ()
>From a user perspective, I think the problem has occured because I have not
>realised there is a default project with a repo pointing to
>http://subcommander.tigris.org/svn/subcommander/trunk and have inadvertently
>loaded my own URI under this tree, and can thus easily be avoided by closing
>the default Subcommander project first.
However, I believe a core dump is still a problem.
Then, in thinking I was only having an edge case, I removed the default
project, made a completely new project, and attempted to add my own URI under
that. The URI I am using is of the form file:///work/some/repo. So I though
I'd try the "..." button, and entered file:///work/ as the start of the URI and
pressed the "..." button, and had another core dump.
This time with the message:
subcommander:
/tmp/buildd/subversion-1.5.1dfsg1/subversion/libsvn_subr/path.c:119:
svn_path_join: Assertion `is_canonical(base, blen)' failed.
(gdb) bt
#0 0x00007fd7d6d03ed5 in raise () from /lib/libc.so.6
#1 0x00007fd7d6d053f3 in abort () from /lib/libc.so.6
#2 0x00007fd7d6cfcdc9 in __assert_fail () from /lib/libc.so.6
#3 0x00007fd7d8cdad6d in svn_path_join () from /usr/lib/libsvn_subr-1.so.1
#4 0x00007fd7d7c0cc28 in svn_repos_find_root_path () from
/usr/lib/libsvn_repos-1.so.1
#5 0x00007fd7d8037ab7 in svn_ra_local__split_URL () from
/usr/lib/libsvn_ra_local-1.so.1
#6 0x00007fd7d80377d7 in ?? () from /usr/lib/libsvn_ra_local-1.so.1
#7 0x00007fd7d8035849 in ?? () from /usr/lib/libsvn_ra_local-1.so.1
#8 0x00000000004f14a4 in ?? ()
#9 0x00000000004d65c3 in ?? ()
#10 0x00000000004dc423 in ?? ()
#11 0x00000000004aabe9 in ?? ()
#12 0x00007fd7d9de9171 in ?? () from /usr/lib/libapr-1.so.0
#13 0x00007fd7d9567fc7 in start_thread () from /lib/libpthread.so.0
#14 0x00007fd7d6da15ad in clone () from /lib/libc.so.6
#15 0x0000000000000000 in ?? ()
So there is a bug processing file:/// URL from the UI for browsing when
selecting a new repo.
After working out to avoid this core dump by simply pasting the entire URI I
have been able to browse my REPO without any further problems.
Also note, my uri file:///work/some/repo, /work is actually a symlink to
removable media under /mnt (which was mounted at the time) so I dont know if
there is an issue with symlinks or not.
-- System Information:
Debian Release: 5.0
APT prefers oldstable
APT policy: (500, 'oldstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages subcommander depends on:
ii libapr1 1.2.12-5 The Apache Portable Runtime Librar
ii libaprutil1 1.2.12+dfsg-8 The Apache Portable Runtime Utilit
ii libc6 2.7-18 GNU C Library: Shared libraries
ii libgcc1 1:4.3.2-1.1 GCC support library
ii libneon26 0.26.4-2+b1 An HTTP and WebDAV client library
ii libqt3-mt 3:3.3.8b-5 Qt GUI Library (Threaded runtime v
ii libssl0.9.8 0.9.8g-15 SSL shared libraries
ii libstdc++6 4.3.2-1.1 The GNU Standard C++ Library v3
ii libsvn1 1.5.1dfsg1-2 Shared libraries used by Subversio
ii libuuid1 1.41.3-1 universally unique id library
ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime
subcommander recommends no packages.
Versions of packages subcommander suggests:
ii subcommander-doc 1.2.2-1 User guide for subcommander
-- no debconf information
--- End Message ---
--- Begin Message ---
Source-Version: 2.0.0~b4-1
Andrew McDonnell write:
Hi,
>
> I have just discovered that subcommander had installed from Etch, as it is
> not in Lenny at all, but for some reason is in testing.
The old version was removed from testing because of crashes and the new
was uploaded too late for the Lenny, that's why there's no subcommander
there.
> So this bug may just be because it is old software, although I dont know why
> it isnt in Lenny,
I assume the bug has already been fixed in the newer version, so I'm
closing the report. Please reopen it if you experience the problem with
2.0.0~b4.
Regards,
robert
--- End Message ---
