Bug 411701

Executable: kdeinit5 PID: 15672 Signal: Segmentation fault (11) Time: 8/9/19

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

Thread 2 (Thread 0x7f659e43a700 (LWP 15677)):
#0  0x00007f65a3dc8729 in __GI___poll (fds=0x7f6598005260, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f65a243fbf6 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007f65a243fd1c in g_main_context_iteration () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007f65a4168063 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x00007f65a41135bb in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x00007f65a3f5e2c6 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x00007f659fa17565 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#7  0x00007f65a3f5f612 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x00007f65a2da2182 in start_thread (arg=<optimized out>) at pthread_create.c:486
#9  0x00007f65a3dd4b1f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7f65a077a780 (LWP 15672)):
[KCrash Handler]
#6  0x00007f659fc65211 in QAbstractSocket::peerAddress() const () from /usr/lib/x86_64-linux-gnu/libQt5Network.so.5
#7  0x00007f65a4ba9e8f in ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/ftp.so
#8  0x00007f65a4baa0f6 in ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/ftp.so
#9  0x00007f65a4baa1a6 in ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/ftp.so
#10 0x00007f65a4baa2f6 in ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/ftp.so
#11 0x00007f65a4baa521 in ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/ftp.so
#12 0x00007f659fe7bd96 in KIO::SlaveBase::dispatch(int, QByteArray const&) () from /usr/lib/x86_64-linux-gnu/libKF5KIOCore.so.5
#13 0x00007f659fe7c5d6 in KIO::SlaveBase::dispatchLoop() () from /usr/lib/x86_64-linux-gnu/libKF5KIOCore.so.5
#14 0x00007f65a4ba7a02 in kdemain () from /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/ftp.so
#15 0x0000560c65fe9e1c in ?? ()
#16 0x0000560c65feaeea in ?? ()
#17 0x0000560c65feb8fb in ?? ()
#18 0x0000560c65fe6645 in ?? ()
#19 0x00007f65a3cddb6b in __libc_start_main (main=0x560c65fe5c70, argc=5, argv=0x7ffd3c2b24a8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffd3c2b2498) at ../csu/libc-start.c:308
#20 0x0000560c65fe72ca in ?? ()
[Inferior 1 (process 15672) detached]

It crashed when using Dolphin in split view. On right tab I had open an ftp address, then I stopped the ftp server on the remote machine and hit F5 on local machine (Dolphin), then the crash happened. See attachment.

Created attachment 122530 [details]
dolphin-kde-kdeinit5-crash-ftp-closed.png

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

Massimiliano, I see no mention of FTP in bug 411441. What did you investigate to come to the conclusion it is the same crash?

(In reply to Christoph Feck from comment #6)
> Massimiliano, I see no mention of FTP in bug 411441. What did you
> investigate to come to the conclusion it is the same crash?

It just looked really similar (same symptom, same triggering application). I took too much of a liberty, I apologize. I reopened.

This is a fairly non-trivial problem.

ftpSendCmd will try to establish a connection when it stopped working for some reason. if that re-establishing still goes wrong the connection is closed as a whole (ftpCloseControlConnection) which means m_control is set to nullptr.

This clashes with fallback logic in various parts of the code. Notably I've seen:

listDir() will call ftpFileExists() after ftpOpenDir() already failed. m_control is nullptr at this point already and fails the assert in ftpSendCmd().

inside ftpOpenDir() if by chance the call made it past ftpFolder() it will call ftpOpenCommand() which calls ftpOpenDataConnection() and that has a similar defect: it calls ftpOpenPASVDataConnection() which can error out on connection establishment but then tries to recover by calling ftpOpenEPSVDataConnection() which again fails because m_control is already null again.

I am profoundly unsure how to best fix this. Perhaps the assertions should really be return conditions.

test scenario for the record though:

```
    void testCrashOnServerDisappearance()
    {
        QProcess daemonProc;
        QUrl url = QUrl("ftp://localhost");
        runDaemon(daemonProc, url, m_remoteDir);
        url.setPath("/");

        // Server disappears after first list and slave crashes
        // subsequently.
        // https://bugs.kde.org/show_bug.cgi?id=411701
        {
            auto job = KIO::listDir(url);
            job->setUiDelegate(nullptr);
            QVERIFY2(job->exec(), qUtf8Printable(job->errorString()));
            QCOMPARE(job->error(), 0);
        }

        daemonProc.kill();
        QVERIFY(daemonProc.waitForFinished());

        {
            auto job = KIO::listDir(url);
            job->setUiDelegate(nullptr);
            QVERIFY2(job->exec(), qUtf8Printable(job->errorString()));
            QCOMPARE(job->error(), 0);
        }
    }
```