Details
-
Bug
-
Resolution: Invalid
-
Not Evaluated
-
None
-
6.6.3
-
None
-
All
Description
I was just running Plasma's `kscreenlocker_greet --testing` through valgrind to see why the screen remains black. Not sure if related, but there's this very nice invalid read backtrace. Quote valgrind:
==10885== Invalid read of size 16 ==10885== at 0x1D0CD698: ??? ==10885== by 0x2A8170FF: ??? ==10885== Address 0x2a81de2e is 27,966 bytes inside a block of size 27,972 alloc'd ==10885== at 0x4843788: malloc (vg_replace_malloc.c:442) ==10885== by 0x7D7EA73: UnknownInlinedFun (qarraydata.cpp:139) ==10885== by 0x7D7EA73: QArrayData::allocate(QArrayData**, long long, long long, long long, QArrayData::AllocationOption) [clone .constprop.0] (qarraydata.cpp:189) ==10885== by 0x7BC228C: UnknownInlinedFun (qarraydata.h:106) ==10885== by 0x7BC228C: QString::fromLatin1(QByteArrayView) (qstring.cpp:5718) ==10885== by 0x881D35A: QString QString::fromLatin1<void>(QByteArray const&) (qstring.h:581) ==10885== by 0x881112A: KSvg::SharedSvgRenderer::load(QByteArray const&, QString const&, QHash<QString, QRectF>&) (svg.cpp:141) ==10885== by 0x8810AA5: KSvg::SharedSvgRenderer::SharedSvgRenderer(QString const&, QString const&, QHash<QString, QRectF>&, QObject*) (svg.cpp:88) ==10885== by 0x88153CA: KSvg::SvgPrivate::createRenderer() (svg.cpp:692) ==10885== by 0x8815CFE: KSvg::SvgPrivate::findAndCacheElementRect(QStringView) (svg.cpp:776) ==10885== by 0x8815BF5: KSvg::SvgPrivate::elementRect(QStringView) (svg.cpp:765) ==10885== by 0x8817AE6: KSvg::Svg::hasElement(QStringView) const (svg.cpp:1035) ==10885== by 0x8817A2A: KSvg::Svg::hasElement(QString const&) const (svg.cpp:1026) ==10885== by 0x88189DF: KSvg::Svg::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_svg.cpp:787)
So we're looking at a location that's 6 bytes short of the end of a long array that was allocated by QString::fromLatin(QByteArrayView). What do we find in qstring.cpp:5718?
d = DataPointer(Data::allocate(ba.size()), ba.size());
Q_CHECK_PTR(d.data());
d.data()[ba.size()] = '\0';
char16_t *dst = d.data();
I could be reading this wrong, of course. But what it looks like to me is that Data::allocate() allocates an array for DataPointer d with size N, and then the third line writes '\0' at element N. Which was not part of the allocation, one would need an array of size (N+1) for that. Again, unless I'm misunderstanding the behavior of Data::allocate().
Which might corrupt some unrelated data that's being read elsewhere, and would explain why valgrind is complaining.