this specifically unsets the m_highlighter which absolutely must not be
present when in loading state (or more specifically: when receiving lines
as-they-appear as opposed to the finished backtrace).
also assert that the widget has no highlighter when loading lines
the highlighter design is fairly wonky, it actually highlights off of the
qtextdocument, but to highlight it needs to know the actual parsed trace
Line entities and they are of course no longer present because the
document only has a text blob. to bridge that disconnect the highlighter
needs to match up the textual lines to the Line entities by their index.
naturally this is a potential bundle of segfault sources when the two
sources no longer align.
unfortunately that is exactly what could happen:
technically speaking drkonqi has two instances of backtracewidget. one
in the main dialog and one in the report dialog. they both use the same
generator though. so what happened was a confusion over which state the
widget needs to be in vis a vis the generator. if the first widget already
loaded a backtrace the generator would be in Loaded state and so would the
widget (i.e. it'd have a highlighter). if the user then proceeds to the
report dialog and they'd get a new widget with a reload button. if the user
then would use the reload button the new widget would be fine, it would
trigger a "reload". the old widget however would not know anything about
the reload and continue to be in Loaded state with a highlighter attached.
as the generator now sends lines to the old and the new widget, the old
widget would receive the lines with a highlighter attached.
bang! the (new) lines disalign with the Line entities in the highlighter
and all hell breaks loose.
this quite possibly fixes all occurrences of the #381644 crasher, but I
wouldn't exclude other points of frailty. as mentioned, the way the
highlighter's connecting textual lines to Line entities is fairly
fragile in of itself.
CHANGELOG: No longer crashes when reloading backtraces under certain circumstances