https://bugs.kde.org/show_bug.cgi?id=517620
--- Comment #4 from Sebastian Müller <[email protected]> --- One more note on your attachment 190694, because your analysis was the piece that proved the client-side path - your backtrace matches my two core dumps frame for frame: #2 QString::fromUtf8_helper #3 Maliit::Wayland::InputMethodContext::zwp_input_method_context_v1_surrounding_text Same function, same call. The one difference is where inside fromUtf8 it dies, and that difference is explained by the garbage magnitude: maliit passes the compositor-supplied cursor/anchor byte offsets as *lengths* into QString::fromUtf8. In my dumps the values were huge or negative-as-int (1.2G / 2.7G), so the allocation itself throws qBadAlloc -> ABRT. In your dump the value was moderate (~278M), so the allocation succeeded and QUtf8::convertToUnicode (your frame #0) then read ~278 MB past the 4 KB source buffer until it hit an unmapped page -> SEGV. Your "effective strlen ~278,000,000 / no null terminator" measurement was exactly that overread distance - there never was a large string; the wayland wire format caps the whole message at 4096 bytes. So: not oversized text, but out-of-range offsets - in your case supplied by Discord/Electron through text-input-v3 and forwarded unvalidated by kwin. The second commit in the MR clamps them at the chokepoint, which fixes your case independently of what the client sends. -- You are receiving this mail because: You are watching all bug changes.
