Created attachment 116189 [details]
New crash information added by DrKonqi

ksysguard (5.13.5) using Qt 5.11.1

- What I was doing when the application crashed:
I closed ksysguard after looking at the cpu, memory, and network rates tab. I upgraded to KF5 5.52.0 earlier today. The crashes I've reported here and before might involve a race condition where different functions or threads tried to free the same memory twice given the traces and the crashes occurred <10% of times I've closed ksysguard.

-- Backtrace (Reduced):
#7  0xb5c92bb2 in operator==(QString const&, QString const&) (s1=..., s2=...) at tools/qstring.cpp:3153
#8  0xb6883f8f in QLabel::setText(QString const&) (this=0xa58fb0, text=...) at widgets/qlabel.cpp:287
#9  0xb7ec449c in TopLevel::answerReceived(int, QList<QByteArray> const&) (this=0x9a0be0, id=1, answerList=...) at /usr/src/debug/ksysguard-5.13.5-1.fc29.i386/gui/ksysguard.cpp:450
#10 0xb753a925 in KSGRD::SensorAgent::processAnswer(char const*, int) (this=0xa05230, buf=0xbe5440 "100.000000\nksysguardd> 256076\nksysguardd> 159744\nksysguardd> 273\nksysguardd> 291\nksysguardd> 5\nksysguardd> 15\nksysguardd> /dev/mapper/fedora-root\t30832636\t25695616\t3547772\t89\t/\n/dev/mapper/fedora-home"..., buflen=615) at /usr/src/debug/libksysguard-5.13.5-1.fc29.i386/ksgrd/SensorAgent.cpp:91
#11 0xb7541e8e in KSGRD::SensorShellAgent::msgRcvd() (this=0xa05230) at /usr/include/qt5/QtCore/qarraydata.h:206

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

Created attachment 116263 [details]
New crash information added by DrKonqi

ksysguard (5.14.3) using Qt 5.11.1

- What I was doing when the application crashed:
I closed ksysguard and drkonqi started. This crash occurred with ksysguard and Plasma 5.14.3, KF5 5.52.0, Qt 5.11.1 in Fedora 29. 

The crashes might be due to a race condition where two parts of the program(s) involved tried to free the same memory since this crash occurred <10% of times I've shut down ksysguard recently and some of the previous ksysguard crashes I've seen had similar traces with a segmentation fault in QLabelPrivate::clearContents at widgets/qlabel.cpp:1302 which was delete picture; as I reported at https://bugs.kde.org/show_bug.cgi?id=350140#c16

This crash was due to a segmentation fault at QLabelPrivate::clearContents() at widgets/qlabel.cpp:1309 which appears to be delete pixmap; at https://code.qt.io/cgit/qt/qtbase.git/tree/src/widgets/widgets/qlabel.cpp

-- Backtrace (Reduced):
#7  0xb684c3ad in QLabelPrivate::clearContents() (this=0xa92c58) at widgets/qlabel.cpp:1309
#8  0xb684cfd5 in QLabel::setText(QString const&) (this=0x9e6430, text=...) at widgets/qlabel.cpp:293
#9  0xb7e8d49c in TopLevel::answerReceived(int, QList<QByteArray> const&) (this=0x9d3d70, id=1, answerList=...) at /usr/src/debug/ksysguard-5.14.3-1.fc29.i386/gui/ksysguard.cpp:450
#10 0xb7503925 in KSGRD::SensorAgent::processAnswer(char const*, int) (this=0xa13c20, buf=0xcb6c40 "38.532108\nksysguardd> 665552\nksysguardd> 616420\nksysguardd> 191488\nksysguardd> 2398204\nksysguardd> 227328\nksysguardd> 61.467888\nksysguardd> 191488\nksysguardd> 227328\nksysguardd> 0\nksysguardd> 0\nksysgu"..., buflen=495) at /usr/src/debug/libksysguard-5.14.3-1.fc29.i386/ksgrd/SensorAgent.cpp:91
#11 0xb750ae8e in KSGRD::SensorShellAgent::msgRcvd() (this=0xa13c20) at /usr/include/qt5/QtCore/qarraydata.h:206

Created attachment 116390 [details]
New crash information added by DrKonqi

ksysguard (5.14.3) using Qt 5.11.1

- What I was doing when the application crashed:

I was looking at the network activity in ksysguard 5.14.3, and then I closed ksysguard. drkonqi appeared. I've reported crashes with similar traces which have occurred < 10% of the times I've closed ksysguard in the last 2 months.

-- Backtrace (Reduced):
#7  0xb5c95bb2 in operator==(QString const&, QString const&) (s1=..., s2=...) at tools/qstring.cpp:3153
#8  0xb6886f8f in QLabel::setText(QString const&) (this=0x1ed6de0, text=...) at widgets/qlabel.cpp:287
#9  0xb7ec749c in TopLevel::answerReceived(int, QList<QByteArray> const&) (this=0x1e42a80, id=1, answerList=...) at /usr/src/debug/ksysguard-5.14.3-1.fc29.i386/gui/ksysguard.cpp:450
#10 0xb753d925 in KSGRD::SensorAgent::processAnswer(char const*, int) (this=0x1ef9870, buf=0x2082740 "100.000000\nksysguardd> 335696\nksysguardd> 37632\nksysguardd> 0\nksysguardd> 0\nksysguardd> 0\nksysguardd> 0\nksysguardd> /dev/mapper/fedora-root\t30832636\t25986096\t3257292\t90\t/\n/dev/mapper/fedora-home\t84853"..., buflen=608) at /usr/src/debug/libksysguard-5.14.3-1.fc29.i386/ksgrd/SensorAgent.cpp:91
#11 0xb7544e8e in KSGRD::SensorShellAgent::msgRcvd() (this=0x1ef9870) at /usr/include/qt5/QtCore/qarraydata.h:206

Those ksysguard crashes with segmentation faults at operator==(QString const&, QString const&) (s1=..., s2=...) at tools/qstring.cpp:3153 seem to involve the line if (s1.d->size != s2.d->size) in the function 

/*!
  \relates QString
  Returns \c true if string \a s1 is equal to string \a s2; otherwise
  returns \c false.

  The comparison is based exclusively on the numeric Unicode values of
  the characters and is very fast, but is not what a human would
  expect. Consider sorting user-interface strings with
  localeAwareCompare().
*/
bool operator==(const QString &s1, const QString &s2) Q_DECL_NOTHROW
{
    if (s1.d->size != s2.d->size)
        return false;

    return qt_compare_strings(s1, s2, Qt::CaseSensitive) == 0;
}

https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/tools/qstring.cpp

The QStrings s1 or s2 might be null due to their memory being freed or some other reason. s1.d->size or s2.d->size might be null pointer dereferences which lead to the segmentation faults. Checking if s1 or s2 are null before the line if (s1.d->size != s2.d->size) might avoid the crashes.

Crashes involving segmentation faults in operator== (s1=..., s2=...) at tools/qstring.cpp:3153 were reported for:
kpat at https://bugs.kde.org/show_bug.cgi?id=363726#c5 
kdeconnectd at https://bugs.kde.org/show_bug.cgi?id=400010#c1 

Suggested fixes are noted on those pages.

I ran valgrind on ksysguard three times. valgrind showed invalid reads and writes each time after I closed ksysguard.  97 invalid reads and 23 invalid writes were listed on both of the first and third runs. 89 invalid reads and 19 invalid writes were listed on the second run. All the invalid reads and writes I looked at involved lines like "Address 0x1133204c is 36 bytes inside a block of size 132 free'd". I think that line meant that memory was being used after it had been freed or use-after-frees had been detected. 

Invalid reads/writes with similar traces to the segmentation faults which I reported before were shown. Invalid reads with a similar trace to the segmentation faults at operator==(QString const&, QString const&) (s1=..., s2=...) at tools/qstring.cpp:3153 were shown twice per run as in the following example

==3167== Invalid read of size 4
==3167==    at 0x67F9BAA: operator==(QString const&, QString const&) (qstring.cpp:3153)
==3167==    by 0x5C6AF8E: QLabel::setText(QString const&) (qlabel.cpp:287)
==3167==    by 0x48DD49B: TopLevel::answerReceived(int, QList<QByteArray> const&) (ksysguard.cpp:450)
==3167==    by 0x5231924: KSGRD::SensorAgent::processAnswer(char const*, int) (SensorAgent.cpp:186)
==3167==    by 0x5238E8D: KSGRD::SensorShellAgent::msgRcvd() (SensorShellAgent.cpp:93)
==3167==    by 0x6959B43: call (qobjectdefs_impl.h:376)
==3167==    by 0x6959B43: QMetaObject::activate(QObject*, int, int, void**) (qobject.cpp:3754)
==3167==    by 0x695A050: QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (qobject.cpp:3633)
==3167==    by 0x68C70F4: QProcess::readyReadStandardOutput(QProcess::QPrivateSignal) (moc_qprocess.cpp:362)
==3167==    by 0x68CC8AA: QProcessPrivate::tryReadFromChannel(QProcessPrivate::Channel*) (qprocess.cpp:1070)
==3167==    by 0x68CCE86: _q_canReadStandardOutput (qprocess.cpp:1081)
==3167==    by 0x68CCE86: QProcess::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_qprocess.cpp:207)
==3167==    by 0x6959A15: QMetaObject::activate(QObject*, int, int, void**) (qobject.cpp:3771)
==3167==    by 0x695A050: QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (qobject.cpp:3633)
==3167==  Address 0xe976c28 is 328 bytes inside a block of size 404 free'd
==3167==    at 0x4836D85: operator delete(void*, unsigned int) (vg_replace_malloc.c:581)
==3167==    by 0x5C6962A: QLabelPrivate::~QLabelPrivate() (qlabel.cpp:110)
==3167==    by 0x6960D9B: cleanup (qscopedpointer.h:60)
==3167==    by 0x6960D9B: ~QScopedPointer (qscopedpointer.h:107)
==3167==    by 0x6960D9B: QObject::~QObject() (qobject.cpp:884)
==3167==    by 0x5B5C095: QWidget::~QWidget() (qwidget.cpp:1564)
==3167==    by 0x5C171A0: QFrame::~QFrame() (qframe.cpp:262)
==3167==    by 0x5C6A5AA: QLabel::~QLabel() (qlabel.cpp:239)
==3167==    by 0x5C6A5ED: QLabel::~QLabel() (qlabel.cpp:243)
==3167==    by 0x695FEF2: QObjectPrivate::deleteChildren() (qobject.cpp:1997)
==3167==    by 0x5B5BFFF: QWidget::~QWidget() (qwidget.cpp:1705)
==3167==    by 0x5CECD5B: QStatusBar::~QStatusBar() (qstatusbar.cpp:251)
==3167==    by 0x5CECD9D: QStatusBar::~QStatusBar() (qstatusbar.cpp:256)
==3167==    by 0x695FEF2: QObjectPrivate::deleteChildren() (qobject.cpp:1997)
==3167==  Block was alloc'd at
==3167==    at 0x4835C89: operator new(unsigned int) (vg_replace_malloc.c:328)
==3167==    by 0x5C69A6F: QLabel::QLabel(QWidget*, QFlags<Qt::WindowType>) (qlabel.cpp:213)
==3167==    by 0x48DB080: TopLevel::TopLevel() (ksysguard.cpp:105)
==3167==    by 0x48DEF92: kdemain (ksysguard.cpp:588)
==3167==    by 0x1090CA: main (in /usr/bin/ksysguard)

Invalid reads with a similar trace to the segmentation faults at QLabelPrivate::clearContents() at widgets/qlabel.cpp specifically at line 1309 were shown once per run as in the following example, although 14-20 other traces per run with QLabelPrivate::clearContents() at different lines of qlabel.cpp at the top of the stack were found.

==3167== Invalid read of size 4
==3167==    at 0x5C6A39D: QLabelPrivate::clearContents() (qlabel.cpp:1309)
==3167==    by 0x5C6AFD4: QLabel::setText(QString const&) (qlabel.cpp:293)
==3167==    by 0x48DD49B: TopLevel::answerReceived(int, QList<QByteArray> const&) (ksysguard.cpp:450)
==3167==    by 0x5231924: KSGRD::SensorAgent::processAnswer(char const*, int) (SensorAgent.cpp:186)
==3167==    by 0x5238E8D: KSGRD::SensorShellAgent::msgRcvd() (SensorShellAgent.cpp:93)
==3167==    by 0x6959B43: call (qobjectdefs_impl.h:376)
==3167==    by 0x6959B43: QMetaObject::activate(QObject*, int, int, void**) (qobject.cpp:3754)
==3167==    by 0x695A050: QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (qobject.cpp:3633)
==3167==    by 0x68C70F4: QProcess::readyReadStandardOutput(QProcess::QPrivateSignal) (moc_qprocess.cpp:362)
==3167==    by 0x68CC8AA: QProcessPrivate::tryReadFromChannel(QProcessPrivate::Channel*) (qprocess.cpp:1070)
==3167==    by 0x68CCE86: _q_canReadStandardOutput (qprocess.cpp:1081)
==3167==    by 0x68CCE86: QProcess::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_qprocess.cpp:207)
==3167==    by 0x6959A15: QMetaObject::activate(QObject*, int, int, void**) (qobject.cpp:3771)
==3167==    by 0x695A050: QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (qobject.cpp:3633)
==3167==  Address 0xe976c2c is 332 bytes inside a block of size 404 free'd
==3167==    at 0x4836D85: operator delete(void*, unsigned int) (vg_replace_malloc.c:581)
==3167==    by 0x5C6962A: QLabelPrivate::~QLabelPrivate() (qlabel.cpp:110)
==3167==    by 0x6960D9B: cleanup (qscopedpointer.h:60)
==3167==    by 0x6960D9B: ~QScopedPointer (qscopedpointer.h:107)
==3167==    by 0x6960D9B: QObject::~QObject() (qobject.cpp:884)
==3167==    by 0x5B5C095: QWidget::~QWidget() (qwidget.cpp:1564)
==3167==    by 0x5C171A0: QFrame::~QFrame() (qframe.cpp:262)
==3167==    by 0x5C6A5AA: QLabel::~QLabel() (qlabel.cpp:239)
==3167==    by 0x5C6A5ED: QLabel::~QLabel() (qlabel.cpp:243)
==3167==    by 0x695FEF2: QObjectPrivate::deleteChildren() (qobject.cpp:1997)
==3167==    by 0x5B5BFFF: QWidget::~QWidget() (qwidget.cpp:1705)
==3167==    by 0x5CECD5B: QStatusBar::~QStatusBar() (qstatusbar.cpp:251)
==3167==    by 0x5CECD9D: QStatusBar::~QStatusBar() (qstatusbar.cpp:256)
==3167==    by 0x695FEF2: QObjectPrivate::deleteChildren() (qobject.cpp:1997)
==3167==  Block was alloc'd at
==3167==    at 0x4835C89: operator new(unsigned int) (vg_replace_malloc.c:328)
==3167==    by 0x5C69A6F: QLabel::QLabel(QWidget*, QFlags<Qt::WindowType>) (qlabel.cpp:213)
==3167==    by 0x48DB080: TopLevel::TopLevel() (ksysguard.cpp:105)
==3167==    by 0x48DEF92: kdemain (ksysguard.cpp:588)
==3167==    by 0x1090CA: main (in /usr/bin/ksysguard)

Invalid reads/writes were common at other points in the stack were common. The segmentation faults might've occurred only when freed memory addresses which had already been allocated to other processes were attempted to be used again by ksysguard. ksysguard didn't crash on the three runs I mentioned using valgrind. The commands I ran were
valgrind --log-file=valgrind-ksysguard-1.txt ksysguard
valgrind --log-file=valgrind-ksysguard-2.txt ksysguard
valgrind --read-var-info=yes --log-file=valgrind-ksysguard-3.txt ksysguard

The third run had --read-var-info=yes as was suggested by the Valgrind manual section 4.2.1 http://valgrind.org/docs/manual/mc-manual.html#mc-manual.badrw
but using that option didn't appear to show more information on the variables involved. I'll attach the log files for the three runs.

Created attachment 116394 [details]
valgrind --log-file=valgrind-ksysguard-1.txt ksysguard output

Created attachment 116395 [details]
valgrind --log-file=valgrind-ksysguard-2.txt ksysguard output

Created attachment 116396 [details]
valgrind --read-var-info=yes --log-file=valgrind-ksysguard-3.txt ksysguard output

Memory leaks were detected with 8-9 definitely lost blocks, 48 indirectly lost blocks, and 19 possibly lost blocks per run. I'm unsure if the segmentation faults are related to those memory leaks. One line I wrote should have been Invalid reads/writes were common at other points in the stack. The invalid reads/writes of freed memory seem to have started earlier in the shutdown process than those which directly caused in the segmentation faults. Memory corruption might have been involved as a result of the use-after-frees.

All of the valgrind runs' first invalid reads were in KSGRD::SensorAgent::processAnswer at SensorAgent.cpp:186 as in the following. All of the other invalid reads or writes have KSGRD::SensorAgent::processAnswer(char const*, int) (SensorAgent.cpp:186) lower in their traces.

==3167== Invalid read of size 4
==3167==    at 0x52311C6: KSGRD::SensorAgent::processAnswer(char const*, int) (SensorAgent.cpp:186)
==3167==    by 0x5238E8D: KSGRD::SensorShellAgent::msgRcvd() (SensorShellAgent.cpp:93)
==3167==    by 0x6959B43: call (qobjectdefs_impl.h:376)
==3167==    by 0x6959B43: QMetaObject::activate(QObject*, int, int, void**) (qobject.cpp:3754)
==3167==    by 0x695A050: QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (qobject.cpp:3633)
==3167==    by 0x68C70F4: QProcess::readyReadStandardOutput(QProcess::QPrivateSignal) (moc_qprocess.cpp:362)
==3167==    by 0x68CC8AA: QProcessPrivate::tryReadFromChannel(QProcessPrivate::Channel*) (qprocess.cpp:1070)
==3167==    by 0x68CCE86: _q_canReadStandardOutput (qprocess.cpp:1081)
==3167==    by 0x68CCE86: QProcess::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_qprocess.cpp:207)
==3167==    by 0x6959A15: QMetaObject::activate(QObject*, int, int, void**) (qobject.cpp:3771)
==3167==    by 0x695A050: QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (qobject.cpp:3633)
==3167==    by 0x6965BA9: QSocketNotifier::activated(int, QSocketNotifier::QPrivateSignal) (moc_qsocketnotifier.cpp:136)
==3167==    by 0x6965F71: QSocketNotifier::event(QEvent*) (qsocketnotifier.cpp:266)
==3167==    by 0x5B1BDA9: QApplicationPrivate::notify_helper(QObject*, QEvent*) (qapplication.cpp:3727)
==3167==  Address 0x1133204c is 36 bytes inside a block of size 132 free'd
==3167==    at 0x4836BC9: operator delete(void*) (vg_replace_malloc.c:576)
==3167==    by 0x48E5C69: TopLevel::~TopLevel() (ksysguard.h:41)
==3167==    by 0x695A77A: QObject::event(QEvent*) (qobject.cpp:1242)
==3167==    by 0x5B6166C: QWidget::event(QEvent*) (qwidget.cpp:9347)
==3167==    by 0x5C880C2: QMainWindow::event(QEvent*) (qmainwindow.cpp:1348)
==3167==    by 0x50148B9: KMainWindow::event(QEvent*) (in /usr/lib/libKF5XmlGui.so.5.52.0)
==3167==    by 0x5061E50: KXmlGuiWindow::event(QEvent*) (in /usr/lib/libKF5XmlGui.so.5.52.0)
==3167==    by 0x48DC18B: TopLevel::event(QEvent*) (ksysguard.cpp:343)
==3167==    by 0x5B1BDA9: QApplicationPrivate::notify_helper(QObject*, QEvent*) (qapplication.cpp:3727)
==3167==    by 0x5B23E58: QApplication::notify(QObject*, QEvent*) (qapplication.cpp:3486)
==3167==    by 0x692EE65: QCoreApplication::notifyInternal2(QObject*, QEvent*) (qcoreapplication.cpp:1048)
==3167==    by 0x6932317: sendEvent (qcoreapplication.h:234)
==3167==    by 0x6932317: QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (qcoreapplication.cpp:1745)
==3167==  Block was alloc'd at
==3167==    at 0x4835C89: operator new(unsigned int) (vg_replace_malloc.c:328)
==3167==    by 0x48DEF86: kdemain (ksysguard.cpp:588)
==3167==    by 0x1090CA: main (in /usr/bin/ksysguard)
==3167== 

SensorAgent.cpp:186 is 
req->client()->answerReceived( req->id(), mAnswerBuffer ); 
https://cgit.kde.org/libksysguard.git/tree/ksgrd/SensorAgent.cpp?h=Plasma/5.14

The invalid reads of a variable in SensorAgent.cpp:186 which had already been freed might be where the invalid reads and writes leading to the segmentation faults I've observed started. delete req and mAnswerBuffer.clear() followed by continue are in if blocks before the req->client()->answerReceived( req->id(), mAnswerBuffer ) line so I'm unsure if that can be reached if those variables are deleted/freed first. The else of the if block SensorAgent.cpp:186 is in might be run if mAnswerBuffer.isEmpty() is true which might lead to an empty mAnswerBuffer being used.

if(!mAnswerBuffer.isEmpty() && mAnswerBuffer[0] == "UNKNOWN COMMAND") {
       /* Notify client that the sensor seems to be no longer available. */
        qCDebug(LIBKSYSGUARD_KSGRD) << "Received UNKNOWN COMMAND for: " << req->request();
		req->client()->sensorLost( req->id() );
	} else {
		// Notify client of newly arrived answer.
		req->client()->answerReceived( req->id(), mAnswerBuffer );
	}

Changing that if block to be something like the following might avoid an empty mAnswerBuffer being used.

if(!mAnswerBuffer.isEmpty()) { 
    if (mAnswerBuffer[0] == "UNKNOWN COMMAND") {
	 /* Notify client that the sensor seems to be no longer available. */
        qCDebug(LIBKSYSGUARD_KSGRD) << "Received UNKNOWN COMMAND for: " << req->request();
	req->client()->sensorLost( req->id() );
    } 
    else {
	// Notify client of newly arrived answer.
	req->client()->answerReceived( req->id(), mAnswerBuffer );
    }
}

I built the ksysguard packages with AddressSanitizer enabled. When I ran ksysguard several times with AddressSanitizer enabled and closed it, memory leaks were shown which were similar to those output by a further valgrind run I did. No use-after-free errors were shown by AddressSanitizer. I'll attach the valgrind and AddressSanitizer output showing memory leaks.

Created attachment 116433 [details]
valgrind --leak-check=yes --show-leak-kinds=definite --log-file=valgrind-ksysguard-5.txt ksysguard output

Created attachment 116434 [details]
AddressSanitizer output from running and closing ksysguard

AddressSanitizer caught a use-after-free error in TopLevel::answerReceived at ksysguard.cpp:450 while ksysguard was closing on the 24th time I ran it. The second function from the top was KSGRD::SensorAgent::processAnswer at SensorAgent.cpp:186 which makes it more likely as being involved in the errors and crashes. The error's invalid read of size 4 and its stack matches the second in the first three valgrind runs I previously mentioned and a later one in the last run. The AddressSanitizer output was the following.

=================================================================
==5225==ERROR: AddressSanitizer: heap-use-after-free on address 0xa95219b8 at pc 0xb78da97e bp 0xbf88b7d8 sp 0xbf88b7c8
READ of size 4 at 0xa95219b8 thread T0
    #0 0xb78da97d in TopLevel::answerReceived(int, QList<QByteArray> const&) /programs/ksysguard/fedora/ksysguard/ksysguard-5.14.3/gui/ksysguard.cpp:450
    #1 0xb6e30924 in KSGRD::SensorAgent::processAnswer(char const*, int) /usr/src/debug/libksysguard-5.14.3-1.fc29.i386/ksgrd/SensorAgent.cpp:186
    #2 0xb6e37e8d in KSGRD::SensorShellAgent::msgRcvd() /usr/src/debug/libksysguard-5.14.3-1.fc29.i386/ksgrd/SensorShellAgent.cpp:93
    #3 0xb56e8b43 in QMetaObject::activate(QObject*, int, int, void**) (/lib/libQt5Core.so.5+0x269b43)
    #4 0xb56e9050 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (/lib/libQt5Core.so.5+0x26a050)
    #5 0xb56560f4 in QProcess::readyReadStandardOutput(QProcess::QPrivateSignal) .moc/moc_qprocess.cpp:362
    #6 0xb565b8aa in QProcessPrivate::tryReadFromChannel(QProcessPrivate::Channel*) io/qprocess.cpp:1070
    #7 0xb565be86 in QProcessPrivate::_q_canReadStandardOutput() io/qprocess.cpp:1081
    #8 0xb565be86 in QProcess::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) .moc/moc_qprocess.cpp:207
    #9 0xb56e8a15 in QMetaObject::activate(QObject*, int, int, void**) (/lib/libQt5Core.so.5+0x269a15)
    #10 0xb56e9050 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (/lib/libQt5Core.so.5+0x26a050)
    #11 0xb56f4ba9 in QSocketNotifier::activated(int, QSocketNotifier::QPrivateSignal) .moc/moc_qsocketnotifier.cpp:136
    #12 0xb56f4f71 in QSocketNotifier::event(QEvent*) (/lib/libQt5Core.so.5+0x275f71)
    #13 0xb6028da9 in QApplicationPrivate::notify_helper(QObject*, QEvent*) kernel/qapplication.cpp:3727
    #14 0xb6030e58 in QApplication::notify(QObject*, QEvent*) kernel/qapplication.cpp:3486
    #15 0xb56bde65 in QCoreApplication::notifyInternal2(QObject*, QEvent*) (/lib/libQt5Core.so.5+0x23ee65)
    #16 0xb5715be3 in socketNotifierSourceDispatch ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:234
    #17 0xaf6e85c4 in g_main_dispatch gmain.c:3182
    #18 0xaf6e89a8 in g_main_context_iterate gmain.c:3920
    #19 0xaf6e8a5a in g_main_context_iteration (/lib/libglib-2.0.so.0+0x4ba5a)
    #20 0xb571515c in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) kernel/qeventdispatcher_glib.cpp:423
    #21 0xa7c29e36  (/lib/libQt5XcbQpa.so.5+0xd6e36)
    #22 0xb56bcb6e in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (/lib/libQt5Core.so.5+0x23db6e)
    #23 0xb56c53e1 in QCoreApplication::exec() (/lib/libQt5Core.so.5+0x2463e1)
    #24 0xb5a64234 in QGuiApplication::exec() (/lib/libQt5Gui.so.5+0xe1234)
    #25 0xb6028d17 in QApplication::exec() (/lib/libQt5Widgets.so.5+0xfcd17)
    #26 0xb78e1027 in kdemain /programs/ksysguard/fedora/ksysguard/ksysguard-5.14.3/gui/ksysguard.cpp:609
    #27 0x4d810a in main (/programs/ksysguard/fedora/ksysguard/ksysguard-5.14.3/i686-redhat-linux-gnu/bin/ksysguard+0x110a)
    #28 0xb506ac08 in __libc_start_main (/lib/libc.so.6+0x1ac08)
    #29 0x4d81b4 in _start (/programs/ksysguard/fedora/ksysguard/ksysguard-5.14.3/i686-redhat-linux-gnu/bin/ksysguard+0x11b4)

0xa95219b8 is located 104 bytes inside of 132-byte region [0xa9521950,0xa95219d4)
freed by thread T0 here:
    #0 0xb7a337f4 in operator delete(void*) (/lib/libasan.so.5+0xf47f4)
    #1 0xb78f5cc0 in TopLevel::~TopLevel() /programs/ksysguard/fedora/ksysguard/ksysguard-5.14.3/i686-redhat-linux-gnu/gui/kdeinit_ksysguard_autogen/EWIEGA46WW/../../../../gui/ksysguard.h:41
    #2 0xb56e977a in QObject::event(QEvent*) (/lib/libQt5Core.so.5+0x26a77a)
    #3 0xb606e66c in QWidget::event(QEvent*) (/lib/libQt5Widgets.so.5+0x14266c)

previously allocated by thread T0 here:
    #0 0xb7a3299c in operator new(unsigned int) (/lib/libasan.so.5+0xf399c)
    #1 0xb78e0d5c in kdemain /programs/ksysguard/fedora/ksysguard/ksysguard-5.14.3/gui/ksysguard.cpp:588
    #2 0x4d810a in main (/programs/ksysguard/fedora/ksysguard/ksysguard-5.14.3/i686-redhat-linux-gnu/bin/ksysguard+0x110a)
    #3 0xb506ac08 in __libc_start_main (/lib/libc.so.6+0x1ac08)

SUMMARY: AddressSanitizer: heap-use-after-free /programs/ksysguard/fedora/ksysguard/ksysguard-5.14.3/gui/ksysguard.cpp:450 in TopLevel::answerReceived(int, QList<QByteArray> const&)
Shadow bytes around the buggy address:
  0x352a42e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 03 fa fa
  0x352a42f0: fa fa fa fa fa fa fd fd fd fd fd fd fd fd fd fd
  0x352a4300: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
  0x352a4310: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x352a4320: fd fd fa fa fa fa fa fa fa fa fd fd fd fd fd fd
=>0x352a4330: fd fd fd fd fd fd fd[fd]fd fd fd fa fa fa fa fa
  0x352a4340: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
  0x352a4350: 00 00 00 00 01 fa fa fa fa fa fa fa fa fa fd fd
  0x352a4360: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x352a4370: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
  0x352a4380: fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==5225==ABORTING

Created attachment 116888 [details]
New crash information added by DrKonqi

ksysguard (5.14.4) using Qt 5.11.1

- What I was doing when the application crashed:

I was troubleshooting the ksysguard crashes in this report using gammaray with the following commands in konsole where the process id of ksysguard was 2506
ksysguard &
gammaray --injector gdb --pid 2506

Other messages shown in the shell during and after the crash were:
QObject::disconnect: No such signal QObject::contentsChanged()
QObject::disconnect:  (receiver name: 'com.kdab.GammaRay.TextDocumentModel')
KCrash: Application 'ksysguard' crashing...
KCrash: Attempting to start /usr/libexec/drkonqi from kdeinit
sock_file=/run/user/1000/kdeinit5__0
QSocketNotifier: Invalid socket 8 and type 'Read', disabling...
QSocketNotifier: Invalid socket 23 and type 'Read', disabling...
QSocketNotifier: Invalid socket 9 and type 'Read', disabling...

Using gdb on previous segmentation faults involving operator==(QString const&, QString const&) (s1=..., s2=...) at tools/qstring.cpp:3153, I observed that s1.d pointed to addresses which were not accessible by the process which had unusually low but not null addresses or unusally high addresses. The invalid pointers are possibly due to memory corruption stemming from the use-after-free errors I reported previously detected using valgrind and AddressSanitizer.

-- Backtrace (Reduced):
#8  0xb5c46bb2 in operator==(QString const&, QString const&) (s1=..., s2=...) at tools/qstring.cpp:3153
#9  0xb6837f8f in QLabel::setText(QString const&) (this=0x2528900, text=...) at widgets/qlabel.cpp:287
#10 0xb7e7849c in TopLevel::answerReceived(int, QList<QByteArray> const&) (this=0x2493b40, id=1, answerList=...) at /usr/src/debug/ksysguard-5.14.4-1.fc29.i386/gui/ksysguard.cpp:450
#11 0xb74ee925 in KSGRD::SensorAgent::processAnswer(char const*, int) (this=0x2516500, buf=0x29dee40 "0.000000\nksysguardd> 61004\nksysguardd> 1216116\nksysguardd> 312560\nksysguardd> 2590460\nksysguardd> 35072\nksysguardd> 312560\nksysguardd> 35072\nksysguardd> /dev/mapper/fedora-root\t30832636\t26792620\t24507"..., buflen=442) at /usr/src/debug/libksysguard-5.14.4-1.fc29.i386/ksgrd/SensorAgent.cpp:91
#12 0xb74f5e8e in KSGRD::SensorShellAgent::msgRcvd() (this=0x2516500) at /usr/include/qt5/QtCore/qarraydata.h:206

Created attachment 117348 [details]
New crash information added by DrKonqi

ksysguard (5.14.4) using Qt 5.11.3

- What I was doing when the application crashed:

I closed ksysguard, and drkonqi appeared. This crash occurred with qt 5.11.3, ksysguard 5.14.4, kf5 5.53 in Fedora 29. 

The use-after-free errors found by valgrind which I previously reported occurred each time I closed ksysguard. I wrote a patch removing delete KSGRD::SensorMgr; in the kdemain function at ksysguard.cpp:611 after the app finishes. When I applied the patch, only the first invalid read use-after-free at SensorAgent.cpp:186 was shown by valgrind. The crashes might be prevented because the use-after-free errors didn't continue to the point where the segmentation fault occurred at qstring.cpp:3153. The crash I'm reporting here is from the Fedora ksysguard-5.14.4-1.fc29 package without the patch I wrote. If anyone has ideas on how to prevent the first use-after-free error at SensorAgent.cpp:186 or otherwise fix the crashes, please let me know.

-- Backtrace (Reduced):
#8  0xb5cf5a22 in operator==(QString const&, QString const&) (s1=..., s2=...) at tools/qstring.cpp:3153
#9  0xb68e6edf in QLabel::setText(QString const&) (this=0xd05260, text=...) at widgets/qlabel.cpp:287
#10 0xb7f4749c in TopLevel::answerReceived(int, QList<QByteArray> const&) (this=0xc71a80, id=1, answerList=...) at /usr/src/debug/ksysguard-5.14.4-1.fc29.i386/gui/ksysguard.cpp:450
#11 0xb759f925 in KSGRD::SensorAgent::processAnswer(char const*, int) (this=0xc86f20, buf=0xea0420 "100.000000\nksysguardd> 327360\nksysguardd> 111360\nksysguardd> 0\nksysguardd> 0\nksysguardd> /dev/mapper/fedora-root\t30832636\t26958848\t2284540\t93\t/\n/dev/mapper/fedora-home\t84853216\t80074544\t974528\t99\t/hom"..., buflen=583) at /usr/src/debug/libksysguard-5.14.4-1.fc29.i386/ksgrd/SensorAgent.cpp:91
#12 0xb75a6e8e in KSGRD::SensorShellAgent::msgRcvd() (this=0xc86f20) at /usr/include/qt5/QtCore/qarraydata.h:206

There is no need to add more backtraces. If your investigation resulted in a possible patch, please add it to https://phabricator.kde.org/differential/diff/create/