D21801: force the backtracewidget into loading state when the generator is loading

2019-06-27 Thread Harald Sitter
This revision was automatically updated to reflect the committed changes.
Closed by commit R871:c2775e7335a1: force the backtracewidget into loading 
state when the generator is loading (authored by sitter).

REPOSITORY
  R871 DrKonqi

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D21801?vs=59790&id=60720

REVISION DETAIL
  https://phabricator.kde.org/D21801

AFFECTED FILES
  src/backtracewidget.cpp

To: sitter, #plasma, apol
Cc: plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, 
ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, mart


D21801: force the backtracewidget into loading state when the generator is loading

2019-06-14 Thread Harald Sitter
sitter created this revision.
sitter added a reviewer: Plasma.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
sitter requested review of this revision.

REVISION SUMMARY
  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
  BUG: 381644
  FIXED-IN: 5.16.1

TEST PLAN
  - killall -SEGV dolphin
  - open drkonqi
  - go to backtrace tab
  - let backtrace
  - click report bug
  - proceed to backtrace page
  - click reload
  - no crashy

REPOSITORY
  R871 DrKonqi

BRANCH
  Plasma/5.16

REVISION DETAIL
  https://phabricator.kde.org/D21801

AFFECTED FILES
  src/backtracewidget.cpp

To: sitter, #plasma
Cc: plasma-devel, LeGast00n, ericadams, jraleigh, GB_2, ragreen, Pitel, 
ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, mart