https://bugs.kde.org/show_bug.cgi?id=523233
--- Comment #2 from vcf <[email protected]> --- Created attachment 194764 --> https://bugs.kde.org/attachment.cgi?id=194764&action=edit Full backtrace attached Full backtrace attached (kate-523233-backtrace.txt), taken from a systemd coredump with debug symbols installed for kate, kf6-ktexteditor and kf6-syntax-highlighting. This happens with plain Kate, no rkward involved (see also bug 523145, which is the same assertion at the same line). 15 identical assertions in my journal between 2026-07-14 and 2026-08-01; the journal does not go back further. Versions: kate 26.04.3, kf6-ktexteditor 6.28.0, kf6-syntax-highlighting 6.28.0, KDE neon on Ubuntu 24.04. ## Crashing stack (thread 1) #14 KateHighlighting::applyFormat (this=0x5e20be3428f0, offset=0, length=9, format=...) at src/syntax/katehighlight.cpp:181 #15 KSyntaxHighlighting::AbstractHighlighter::highlightLine at src/lib/abstracthighlighter.cpp:381 #16 KateHighlighting::doHighlight (prevLine=0x0, ...) at src/syntax/katehighlight.cpp:150 #17 KateBuffer::computeFoldings (line=0) at src/document/katebuffer.cpp:423 #18 KateViewInternal::updateFoldingMarkersHighlighting at src/view/kateviewinternal.cpp:2431 #19 KateViewInternal::focusOutEvent at src/view/kateviewinternal.cpp:4067 The document is highlighted as Bash and line 0 is "#!/bin/sh" (9 characters, which matches offset=0 length=9). The crash is triggered by the view losing focus, which recomputes foldings from line 0. ## What the core dump shows The KateHighlighting instance: iName = "Bash" identifier = ":/org.kde.syntax-highlighting/syntax/bash.xml" iSection = "Scripts" m_formats.size() = 78 m_formatsIdToIndex.size() = 78 (contiguous ids 58..135) Sampling m_formats confirms Bash's own formats ARE registered: id=58 Bash | Normal Text id=59 Bash | Comment id=60 Bash | Keyword id=78 Bash | Pattern id=99 Modelines | Comment id=107 SPDX-Comments | SPDX Tag id=118 reStructuredText | SubstitutionReference The Format actually passed to applyFormat: (KSyntaxHighlighting::FormatPrivate *) 0x5e20b9e25620 definitionName = "Bash" name = "Comment" id = 2 defaultStyle = KSyntaxHighlighting::Theme::Comment So "Bash / Comment" exists on both sides, but with two different ids: the lookup table has it as id 59, while the highlighter hands over id 2. The lookup fails and the assertion fires. The definition currently held by the highlighter: AbstractHighlighterPrivate::m_definition -> DefinitionData 0x5e20bc81d3e0 (shared_ptr use count 5) name = "Bash" fileName = ":/org.kde.syntax-highlighting/syntax/bash.xml" repo = 0x5e20b9f1fbf0 ## Interpretation Format ids are allocated per repository, in definition.cpp: formatData->id = RepositoryPrivate::get(repo)->nextFormatId(); An id of 2 means Bash was among the very first definitions loaded in whatever repository produced that Format, whereas the ids in m_formatsIdToIndex start at 58, so they come from a state where 57 formats had already been allocated. In other words two distinct instantiations of the Bash definition, with disjoint format id ranges, coexist in the process. KateHighlighting built its lookup table from one of them, while AbstractHighlighter is highlighting with contexts belonging to the other. Whether that comes from a second Repository instance or from a repository reload that left the old DefinitionData alive (the shared_ptr use count of 5 shows it is still referenced) is something you are better placed to determine than I am. ## One note on the QuickAnnotatingTools theory The "Unable to open QuickAnnotatingTools XML definition" warning does appear in my journal too, 36 seconds before the crash. I do not think it is the cause: okularpart.so does not link against libKF6SyntaxHighlighting, so a failed Okular annotation-tool resource cannot affect KSyntaxHighlighting format ids. It looks like a coincidental warning from the preview part being loaded. -- You are receiving this mail because: You are watching all bug changes.
