OK, I think I know how to reproduce this 100% of the time:

1. Pair
2. Connect to some OpenVPN server from your PC (i.e connect to VPN).
3. Put your PC to sleep.
4. Resume from sleep. The phone should no longer be paired. 
(Thus is basically what the bug is about: KDE connect stops working are resuming from sleep, provided you were using VPN before putting your PC to sleep.)

5. Observe that you've lost your OpenVPN connection (it doesn't reconnect on suspend on Kubuntu), otherwise disconnect.
6. Toggle wifi on and off on your phone, in an attempt to re-establish the pairing (it won't work). 
7. You should now get a kdeconnectd crash message.

I've repeating this series of steps twice, with the same result.


The only way I've found to re-establish the pairing is to reboot the phone. I'll try to see if rebooting the PC or logging in out helps.

Crash report after logging out and logging back in.

-------------------------------------------------------

Application: kdeconnectd (kdeconnectd), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f2af980dc80 (LWP 27522))]

Thread 4 (Thread 0x7f2af6124700 (LWP 27528)):
#0  0x00007f2afdb30729 in __GI___poll (fds=0x7f2aec004a30, nfds=1, timeout=9280) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f2afc2a3bf6 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007f2afc2a3d1c in g_main_context_iteration () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007f2afe0b2063 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x00007f2afe05d5bb in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x00007f2afdea82c6 in QThread::exec() () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x00007f2afdea9612 in  () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#7  0x00007f2afd9ff182 in start_thread (arg=<optimized out>) at pthread_create.c:486
#8  0x00007f2afdb3cb1f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 3 (Thread 0x7f2af6925700 (LWP 27527)):
#0  0x00007f2afdb2bfb4 in __GI___libc_read (nbytes=16, buf=0x7f2af6924b50, fd=6) at ../sysdeps/unix/sysv/linux/read.c:26
#1  0x00007f2afdb2bfb4 in __GI___libc_read (fd=6, buf=0x7f2af6924b50, nbytes=16) at ../sysdeps/unix/sysv/linux/read.c:24
#2  0x00007f2afc2ea410 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007f2afc2a36cf in g_main_context_check () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x00007f2afc2a3ba0 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007f2afc2a3d1c in g_main_context_iteration () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#6  0x00007f2afe0b2063 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#7  0x00007f2afe05d5bb in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x00007f2afdea82c6 in QThread::exec() () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#9  0x00007f2afd3d0565 in  () at /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#10 0x00007f2afdea9612 in  () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x00007f2afd9ff182 in start_thread (arg=<optimized out>) at pthread_create.c:486
#12 0x00007f2afdb3cb1f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 2 (Thread 0x7f2af8562700 (LWP 27524)):
#0  0x00007f2afdb30729 in __GI___poll (fds=0x7f2af8561ca8, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f2afbf44917 in  () at /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x00007f2afbf4653a in xcb_wait_for_event () at /usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x00007f2af91376a8 in  () at /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#4  0x00007f2afdea9612 in  () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x00007f2afd9ff182 in start_thread (arg=<optimized out>) at pthread_create.c:486
#6  0x00007f2afdb3cb1f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7f2af980dc80 (LWP 27522)):
[KCrash Handler]
#6  0x00007f2afdf27f23 in operator==(QString const&, QString const&) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#7  0x00007f2afefa577c in KNotification::setTitle(QString const&) () at /usr/lib/x86_64-linux-gnu/libKF5Notifications.so.5
#8  0x00007f2ae7b79009 in  () at /usr/lib/x86_64-linux-gnu/qt5/plugins/kdeconnect/kdeconnect_notifications.so
#9  0x00007f2ae7b80a2d in  () at /usr/lib/x86_64-linux-gnu/qt5/plugins/kdeconnect/kdeconnect_notifications.so
#10 0x00007f2ae7b7c7ea in  () at /usr/lib/x86_64-linux-gnu/qt5/plugins/kdeconnect/kdeconnect_notifications.so
#11 0x00007f2aff187488 in Device::privateReceivedPacket(NetworkPacket const&) () at /usr/lib/x86_64-linux-gnu/libkdeconnectcore.so.1
#12 0x00007f2afe088563 in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#13 0x00007f2aff18e365 in  () at /usr/lib/x86_64-linux-gnu/libkdeconnectcore.so.1
#14 0x00007f2aff15d22e in LanDeviceLink::dataReceived() () at /usr/lib/x86_64-linux-gnu/libkdeconnectcore.so.1
#15 0x00007f2afe088563 in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x00007f2aff164cc0 in SocketLineReader::dataReceived() () at /usr/lib/x86_64-linux-gnu/libkdeconnectcore.so.1
#17 0x00007f2afe088563 in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#18 0x00007f2afd985027 in  () at /usr/lib/x86_64-linux-gnu/libQt5Network.so.5
#19 0x00007f2afd9623d1 in  () at /usr/lib/x86_64-linux-gnu/libQt5Network.so.5
#20 0x00007f2afe088426 in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#21 0x00007f2afd927753 in  () at /usr/lib/x86_64-linux-gnu/libQt5Network.so.5
#22 0x00007f2afd9277e0 in  () at /usr/lib/x86_64-linux-gnu/libQt5Network.so.5
#23 0x00007f2afd9397f1 in  () at /usr/lib/x86_64-linux-gnu/libQt5Network.so.5
#24 0x00007f2afea24551 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#25 0x00007f2afea2b930 in QApplication::notify(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#26 0x00007f2afe05e8e9 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#27 0x00007f2afe0b2c85 in  () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#28 0x00007f2afc2a39ee in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#29 0x00007f2afc2a3c88 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#30 0x00007f2afc2a3d1c in g_main_context_iteration () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#31 0x00007f2afe0b2047 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#32 0x00007f2afe05d5bb in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#33 0x00007f2afe0655e2 in QCoreApplication::exec() () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#34 0x00005627e96213b4 in  ()
#35 0x00007f2afda45b6b in __libc_start_main (main=0x5627e96212b0, argc=1, argv=0x7fff0d75dc98, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff0d75dc88) at ../csu/libc-start.c:308
#36 0x00005627e962141a in _start ()
[Inferior 1 (process 27522) detached]

OK, for some reason after logging out I can see the phone in the KCM module but the Android app can't find my PC. Obviously the plasmoid says "no devices found"

CONCLUSION:
=========================================================

I've unpaired the device on in the Android app and then repaired. The connection works now and persists after resume from suspend. 

Problems still persist however: I've just unpaired the device again, to test - and now again I can't pair it back (the PC is not visible from the app). Experiencing the same crashes with kdeconectd. So clearly the pairing the extremely fragile.


=========================================================
RELATED:

I would strongly suggest adding an "soft unpair" feature, one that merely disconnects but saves all the permissions: 

1. This would allow users to quickly unbork the app, which is important given the high failure rate of pairing. 

2. Furthermore, the current  "unpair" button is just dangerous, since users are given no warning that if they tap it all their app permissions will be lost. Many users will attempt to tap it in the hopes of re-establishing the connection - I know I did and was surprised when I had to re-enable all the permissions and settings (at least 20 taps, quite tedious)

I have filed a separate bug for this here #410360

(That's Bug #410360)

SUMMARY
========================
Looks like KDEConnect craps out whenever the interface changes without KDEConnect running. It keeps connecting to the last interface it remembers. This would explain why, for example you can re-pair your phone after closing kdeconnectd, then closing the VPN connection. When you resume the service, it still thinks there is a VPN running.

Or that's part of what's going on here anyway at any rate.

Judging by the backtrace it's the same crash as in https://bugs.kde.org/show_bug.cgi?id=400010 which is fixed in 1.3.5, which will be released any moment

*** This bug has been marked as a duplicate of bug 400010 ***