| Summary: | Plasma crashes in PlasmaAppletItem::matches() when opening plasma widgets with the system language set to something other than English | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Johannes Carraro <johannes.carraro> |
| Component: | Widget Explorer | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | akselmo, bharadwaj.raju777, git, kde, kishore96, nate, vasua.ukraine |
| Priority: | NOR | Keywords: | drkonqi |
| Version: | 5.24.3 | ||
| Target Milestone: | 1.0 | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Johannes Carraro
2022-04-04 12:27:58 UTC
#7 qt_starts_with (cs=Qt::CaseInsensitive, needle=..., haystack=...) at text/qstring.cpp:11974
#8 QStringRef::startsWith (this=this@entry=0xa292918, str=..., cs=cs@entry=Qt::CaseInsensitive) at text/qstring.cpp:11748
#9 0x00007fea12ad5c62 in PlasmaAppletItem::matches (this=0x98fcc60, pattern=...) at /usr/src/debug/plasma5-workspace-5.24.3-bp154.1.1.x86_64/components/shellprivate/widgetexplorer/plasmaappletitemmodel.cpp:137
Code is:
// Add English name and keywords so users in other languages won't have to switch IME when searching.
if (!QLocale().name().startsWith(QLatin1String("en_"))) {
const QString name(rawData[QStringLiteral("KPlugin")][QStringLiteral("Name")].toString());
keywords << &name << m_info.value(QStringLiteral("Keywords"), QString()).splitRef(QLatin1Char(';'), Qt::SkipEmptyParts);
}
for (const auto &keyword : keywords) {
if (keyword.startsWith(pattern, Qt::CaseInsensitive)) {
return true;
}
}
Seems like maybe keywords is empty, as right now we are assuming it's not.
1. Does literally any text you type into the search field cause it to crash, or only some text?
2. Are you using your system in a language that's not English? If so, does the crashing stop if you switch to English?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! *** Bug 453667 has been marked as a duplicate of this bug. *** Got another report with the same backtrace from someone also using Plasma with a non-English language; re-opening. Vasua, does the crash go away if you temporarily switch the system language to English? (In reply to Nate Graham from comment #5) > Got another report with the same backtrace from someone also using Plasma > with a non-English language; re-opening. > > Vasua, does the crash go away if you temporarily switch the system language > to English? Not the original reporter, but I cannot reproduce this with my System language set to Tamil or Ukrainian, so I guess something else might also be needed to reproduce this. I tried typing both Tamil and Latin text. Operating System: KDE neon Unstable Edition KDE Plasma version: 5.25.80 Kde frameworks version: 5.96.0 Qt version: 5.15.4 Kernel: 5.13.0-51-generic (64-bit) Graphics: X11 for (const auto &keyword : keywords) {
if (keyword.startsWith(pattern, Qt::CaseInsensitive)) {
return true;
}
}
> Seems like maybe keywords is empty, as right now we are assuming it's not.
That can't be it. If keywords was empty none of the loop body would have run. And since from the trace it got into QString code means there was some QString there which it operated on. The crash is somehow happening in Qt's string comparison code itself. Maybe some invalid Unicode somewhere. It would be nice to have the actual values of the strings being compared, if someone can use GDB to get that.
|