CLONE - ArrayIndexOutOfBoundsException when opening a DSL Rule editor

Stack trace snippet:

java.lang.ArrayIndexOutOfBoundsException: 1
at org.eclipse.swt.custom.StyledTextRenderer.calculateClientArea(StyledTextRenderer.java:230)
at org.eclipse.swt.custom.StyledText.handleResize(StyledText.java:6165)
at org.eclipse.swt.custom.StyledText$7.handleEvent(StyledText.java:5658)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1077)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1058)
at org.eclipse.swt.widgets.Control.WM_SIZE(Control.java:4813)
at org.eclipse.swt.widgets.Scrollable.WM_SIZE(Scrollable.java:291)
at org.eclipse.swt.widgets.Composite.WM_SIZE(Composite.java:1653)
at org.eclipse.swt.widgets.Canvas.WM_SIZE(Canvas.java:454)
at org.eclipse.swt.widgets.Control.windowProc(Control.java:4234)
at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:4873)
at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method)
at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:2454)
at org.eclipse.swt.widgets.Scrollable.callWindowProc(Scrollable.java:80)
at org.eclipse.swt.widgets.Control.WM_WINDOWPOSCHANGED(Control.java:4970)
at org.eclipse.swt.widgets.Canvas.WM_WINDOWPOSCHANGED(Canvas.java:460)
at org.eclipse.swt.widgets.Control.windowProc(Control.java:4244)
at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:4873)
at org.eclipse.swt.internal.win32.OS.SetWindowPos(Native Method)
at org.eclipse.swt.widgets.Widget.SetWindowPos(Widget.java:1456)
at org.eclipse.swt.widgets.Control.forceResize(Control.java:1018)
at org.eclipse.swt.widgets.ScrollBar.getThumbTrackBounds(ScrollBar.java:464)
at org.eclipse.jface.text.source.SourceViewer$RulerLayout.computeScrollArrowHeights(SourceViewer.java:217)
at org.eclipse.jface.text.source.SourceViewer$RulerLayout.getVerticalScrollArrowHeights(SourceViewer.java:196)
at org.eclipse.jface.text.source.SourceViewer$RulerLayout.layout(SourceViewer.java:155)
at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1275)
at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1261)
at org.eclipse.swt.widgets.Composite.layout(Composite.java:664)
at org.eclipse.swt.widgets.Composite.layout(Composite.java:622)
at org.eclipse.jface.text.source.CompositeRuler.layoutTextViewer(CompositeRuler.java:611)
at org.eclipse.jface.text.source.CompositeRuler.addDecorator(CompositeRuler.java:565)
at org.eclipse.jface.text.source.projection.ProjectionViewer.addVerticalRulerColumn(ProjectionViewer.java:1289)
at org.eclipse.jface.text.source.projection.ProjectionSupport.doEnableProjection(ProjectionSupport.java:310)
at org.eclipse.jface.text.source.projection.ProjectionSupport$ProjectionListener.projectionEnabled(ProjectionSupport.java:143)
at org.eclipse.jface.text.source.projection.ProjectionViewer.fireProjectionEnabled(ProjectionViewer.java:489)
at org.eclipse.jface.text.source.projection.ProjectionViewer.enableProjection(ProjectionViewer.java:537)
at org.eclipse.jface.text.source.projection.ProjectionViewer.doOperation(ProjectionViewer.java:1441)
at org.drools.eclipse.editors.AbstractRuleEditor.createPartControl(Unknown Source)
at org.eclipse.ui.part.MultiPageEditorPart.addPage(MultiPageEditorPart.java:241)
at org.eclipse.ui.forms.editor.FormEditor.addPage(FormEditor.java:325)
at org.eclipse.ui.part.MultiPageEditorPart.addPage(MultiPageEditorPart.java:211)
at org.eclipse.ui.forms.editor.FormEditor.addPage(FormEditor.java:308)
at org.drools.eclipse.dsl.editor.DSLRuleEditor2.addPages(Unknown Source)
at org.eclipse.ui.forms.editor.FormEditor.createPages(FormEditor.java:138)
at org.eclipse.ui.part.MultiPageEditorPart.createPartControl(MultiPageEditorPart.java:348)

The issue seems to be platform-dependent, as I'm not getting any exceptions in a gtk.linux.x86 build.

Some debugging revealed that StyledTextRenderer's internal data structures assume a different number of lines present than what content.getLineCount() returns in calculateClientArea(); these two values are usually kept in sync with the use of TextChangeListeners. I think that because of TransformedDocument's lazy update mechanism, new state can be returned to the renderer without firing a corresponding text change event first.