Bug#945443: git-svn fails with "error: git-svn died of signal 11"

2020-03-26 Thread James McCoy
Control: reassign -1 libsvn1 1.10.4-1
Control: affects -1 git-svn
Control: tag -1 fixed-upstream

On Tue, Dec 10, 2019 at 07:11:59PM +0100, Bernhard Übelacker wrote:
> In [1] gets a temporary KAboutData object created, with
> string parameters created by QStringLiteral. Therefore
> it looks like QStrings created from that have also a
> private d member pointing to the static data segment of
> the library libsvn_auth_kwallet-1.so.1.
> 
> Inside KAboutData::setApplicationData another KAboutData
> object get created which gets a shared copy of the d member,
> therefore also pointer to the QStringLiterals.
> 
> Later the library libsvn_auth_kwallet-1.so.1 gets unloaded.
> 
> Then on process end the exit handlers try to delete
> the KAboutData which tries to access the now invalid pointers
> to the static data segment of the library
> libsvn_auth_kwallet-1.so.1

Thanks for the investigation and patch.  This is now fixed upstream.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB



Bug#945443: git-svn fails with "error: git-svn died of signal 11"

2019-12-10 Thread Bernhard Übelacker
Control: tags -1 + upstream patch


Dear Maintainer,
I think I found the issue.

In [1] gets a temporary KAboutData object created, with
string parameters created by QStringLiteral. Therefore
it looks like QStrings created from that have also a
private d member pointing to the static data segment of
the library libsvn_auth_kwallet-1.so.1.

Inside KAboutData::setApplicationData another KAboutData
object get created which gets a shared copy of the d member,
therefore also pointer to the QStringLiterals.

Later the library libsvn_auth_kwallet-1.so.1 gets unloaded.

Then on process end the exit handlers try to delete
the KAboutData which tries to access the now invalid pointers
to the static data segment of the library
libsvn_auth_kwallet-1.so.1

---

Attached patch changes the QStringLiteral to QString, therefore
also temporary QString objects should be created, which can be
destroyed even when the shared library got unloaded.

Another possible solution could be if KAboutData would create
deep copies of its strings at this assignment [2].

---

I did not really find an upstream bug in the svn tracker [3].

Just a bug at kde.org [5] which refrences also the
bug [4] found by Christin.


Kind regards,
Bernhard



[1] 
https://sources.debian.org/src/subversion/1.13.0-1/subversion/libsvn_auth_kwallet/kwallet.cpp/#L230

https://sources.debian.org/src/subversion/1.13.0-1/subversion/libsvn_auth_kwallet/kwallet.cpp/#L312
[2] 
https://sources.debian.org/src/kcoreaddons/5.54.0-1/src/lib/kaboutdata.cpp/#L598

[3] https://issues.apache.org/jira/issues/?jql=project%20%3D%20SVN

[4] https://bugs.archlinux.org/task/60005
[5] https://bugs.kde.org/show_bug.cgi?id=407271


(gdb) bt
#0  0x758e3e64 in std::__atomic_base::load(std::memory_order) 
const (__m=std::memory_order_relaxed, this=0x75a23280) at 
/usr/include/c++/8/bits/atomic_base.h:390
#1  0x758e3e64 in QAtomicOps::load(std::atomic const&) 
(_q_value=...) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qatomic_cxx11.h:227
#2  0x758e3e64 in QBasicAtomicInteger::load() const 
(this=0x75a23280) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qbasicatomic.h:103
#3  0x758e3e64 in QtPrivate::RefCount::deref() (this=0x75a23280) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qrefcount.h:66
#4  0x758e3e64 in QString::~QString() (this=0x569742d0, 
__in_chrg=) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qstring.h:1130
#5  0x758e3e64 in KAboutData::Private::~Private() (this=0x569742d0, 
__in_chrg=) at ./src/lib/kaboutdata.cpp:460
#6  0x758e3e64 in KAboutData::~KAboutData() (this=0x56972700, 
__in_chrg=) at ./src/lib/kaboutdata.cpp:581
#7  0x758e410d in KAboutDataRegistry::~KAboutDataRegistry() 
(this=0x7595a6e0 <(anonymous 
namespace)::Q_QGS_s_registry::innerFunction()::holder>, __in_chrg=) at ./src/lib/kaboutdata.cpp:1040
#8  0x758e410d in (anonymous 
namespace)::Q_QGS_s_registry::Holder::~Holder() (this=0x7595a6e0 
<(anonymous namespace)::Q_QGS_s_registry::innerFunction()::holder>, 
__in_chrg=) at ./src/lib/kaboutdata.cpp:1040
#9  0x77c87d8c in __run_exit_handlers (status=0, listp=0x77e09718 
<__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, 
run_dtors=run_dtors@entry=true) at exit.c:108
#10 0x77c87eba in __GI_exit (status=) at exit.c:139
#11 0x555883f6 in main (argc=, argv=, 
env=) at perlmain.c:166
Description: Avoid crash in __run_exit_handlers by using QString instead of QStringLiteral
 If QStringLiteral is used then pointer to segments in the
 shared library libsvn_auth_kwallet-1.so.1 are passed to
 the KAboutData::Private object, which unfortuantely makes
 no deep copy.
 Later in the exit handler when the KAboutData object gets
 destroyed, that pointer are again accessed and trigger the
 crash.

Author: Bernhard Übelacker 

Bug-Debian: https://bugs.debian.org/945443
Bug-Kde: https://bugs.kde.org/show_bug.cgi?id=407271
Bug-Arch: https://bugs.archlinux.org/task/60005

Forwarded: no
Last-Update: 2019-12-10

--- subversion-1.10.4.orig/subversion/libsvn_auth_kwallet/kwallet.cpp
+++ subversion-1.10.4/subversion/libsvn_auth_kwallet/kwallet.cpp
@@ -227,10 +227,10 @@ kwallet_password_get(svn_boolean_t *done
   KLocalizedString::setApplicationDomain("subversion"); /* translation domain */
 
   /* componentName appears in KDE GUI prompts */
-  KAboutData aboutData(QStringLiteral("subversion"), /* componentName */
+  KAboutData aboutData(QString("subversion"),/* componentName */
i18n(get_application_name(parameters,
  pool)), /* displayName */
-   QStringLiteral(SVN_VER_NUMBER));
+   QString(SVN_VER_NUMBER));
   KAboutData::setApplicationData(aboutData);
 #else
   KCmdLineArgs::init(q_argc, q_argv,
@@ -309,10 +309,10 @@ kwallet_password_set(svn_boolean_t *done
   KLocalizedString::setApplicationDomain("subversion"); /* 

Bug#945443: git-svn fails with "error: git-svn died of signal 11"

2019-12-10 Thread christian_k...@gmx.net

Hello Bernhard,

I have installed the package and get this:

...

Dez 10 10:08:28 uranus kernel: git-svn[6712]: segfault at 7f1a38b6c280 
ip 7f1a381b5e64 sp 7fff911177c0 error 4 in 
libKF5CoreAddons.so.5.54.0[7f1a381ab000+6]
Dez 10 10:08:28 uranus kernel: Code: f8 ff 74 06 f0 83 2f 01 74 7c 48 8b 
7b 08 8b 07 85 c0 0f 84 93 00 00 00 83 f8 ff 74 0a f0 83 2f 01 0f 84 1f 
02 00 00 48 8b 03 <8b> 10 85 d2 74 1e 83 fa ff 74 06 f0 83 28 01 74 13 
48 8b 7d 00 48
Dez 10 10:08:28 uranus systemd[1]: Created slice 
system-systemd\x2dcoredump.slice.
Dez 10 10:08:28 uranus systemd[1]: Started Process Core Dump (PID 
6781/UID 0).
Dez 10 10:08:28 uranus systemd-coredump[6782]: Process 6712 (git-svn) of 
user 10002 dumped core.


   Stack trace of thread 6712:
   #0 0x7f1a381b5e64 
_ZN10KAboutDataD1Ev (libKF5CoreAddons.so.5)
   #1 0x7f1a381b610d 
n/a (libKF5CoreAddons.so.5)
   #2 0x7f1a3a649d8c 
__run_exit_handlers (libc.so.6)
   #3 0x7f1a3a649eba 
__GI_exit (libc.so.6)
   #4 0x556c644563f6 
main (perl)
   #5 0x7f1a3a63409b 
__libc_start_main (libc.so.6)
   #6 0x556c6445644a 
_start (perl)
Dez 10 10:08:28 uranus systemd[1]: systemd-coredump@0-6781-0.service: 
Succeeded.


...


I have found another bug report for this: 
https://bugs.archlinux.org/task/60005.


I'm using kwallet, it seems to be the same issue.


Best regards,
Christian




Bug#945443: git-svn fails with "error: git-svn died of signal 11"

2019-12-09 Thread Bernhard Übelacker
Hello Christian,
if you still see this crash, maybe you could install the
package systemd-coredump.

If then a process crashes again some more information
should be visible at the end of:

journalctl --no-pager

Kind regards,
Bernhard



Bug#945443: git-svn fails with "error: git-svn died of signal 11"

2019-11-24 Thread christian_k...@gmx.net

Package:    gtk-svn
Version:    1:2.20.1-2


When I call git svn fetch, git-svn returns an error message after operation

error: git-svn died of signal 11


Here is the transcript:

$ git svn fetch
org.kde.kwindowsystem: Could not find any platform plugin
error: git-svn died of signal 11
$


Best regards,
Christian