#675 Refactoring before a warning marker can cause broken internal state

v0.5.x
closed-out-of-date
nobody
None
5
2016-05-12
2014-07-15
No

I'm using EPIC as part of an RCP app where the application allows to inject text snippets into the editor. This is done through the standard Eclipse Refactoring API using the PerformRefactoringOperation class and a refactoring that creates a number of TextFileChange objects for the actual insertions. After the injection the new code is formatted using EPIC's SourceFormatter class and the original text is replaced with that formatted version. Last the application enforces a saving of the editor by setting the corresponding TextBuffer object to be dirty and saving it.

When having a perl script that is longer than the editor size and having a warning marker in the first function defined in that script then injecting such text seems to cause some kind of internal state corruption. This is visible by eventually having a white number ruler as well as never reaching line '1' in the number ruler when scrolling down and up again. Instead the number ruler will show a seemingly random number larger than one at the top line (see the attached screenshot).

Along with that visual glitch there are errors logged by Eclipse in the workspace log coming from some sanity checks in the various Editor-related classes:

!ENTRY org.eclipse.ui 4 0 2014-07-15 12:28:32.099
!MESSAGE Unhandled event loop exception
!STACK 0
java.lang.IllegalStateException: startLine (4) does not match endLine (3)
    at org.eclipse.jface.text.projection.ProjectionMapping.toImageLine(ProjectionMapping.java:480)
    at org.eclipse.jface.text.TextViewer.modelLine2WidgetLine(TextViewer.java:5272)
    at org.eclipse.jface.text.JFaceTextUtil.modelLineToWidgetLine(JFaceTextUtil.java:224)
    at org.eclipse.jface.internal.text.source.DiffPainter.paintLine(DiffPainter.java:220)
    at org.eclipse.jface.internal.text.source.DiffPainter.paint(DiffPainter.java:158)
    at org.eclipse.jface.text.source.LineNumberChangeRulerColumn.doPaint(LineNumberChangeRulerColumn.java:190)
    at org.eclipse.jface.text.source.LineNumberRulerColumn.doubleBufferPaint(LineNumberRulerColumn.java:703)
    at org.eclipse.jface.text.source.LineNumberRulerColumn.redraw(LineNumberRulerColumn.java:859)
    at org.eclipse.jface.text.source.LineNumberRulerColumn$InternalListener.viewportChanged(LineNumberRulerColumn.java:76)
    at org.eclipse.jface.text.TextViewer.updateViewportListeners(TextViewer.java:3115)
    at org.eclipse.jface.text.TextViewer$ViewportGuard.widgetSelected(TextViewer.java:332)
    at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:240)
    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.sendSelectionEvent(Widget.java:1094)
    at org.eclipse.swt.widgets.ScrollBar.wmScrollChild(ScrollBar.java:1046)
    at org.eclipse.swt.widgets.Scrollable.wmScroll(Scrollable.java:502)
    at org.eclipse.swt.widgets.Scrollable.WM_VSCROLL(Scrollable.java:308)
    at org.eclipse.swt.widgets.Control.windowProc(Control.java:4615)
    at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341)
    at org.eclipse.swt.widgets.Display.windowProc(Display.java:4972)
    at org.eclipse.swt.internal.win32.OS.SendMessageW(Native Method)
    at org.eclipse.swt.internal.win32.OS.SendMessage(OS.java:3275)
    at org.eclipse.swt.widgets.Scrollable.wmScrollWheel(Scrollable.java:402)
    at org.eclipse.swt.widgets.Scrollable.WM_MOUSEWHEEL(Scrollable.java:286)
    at org.eclipse.swt.widgets.Control.windowProc(Control.java:4576)
    at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341)
    at org.eclipse.swt.widgets.Display.windowProc(Display.java:4985)
    at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
    at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2531)
    at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3752)
    at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2701)
    at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2665)
    at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499)
    at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679)
    at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
    at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:668)
    at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
    at com.froglogic.squish.ide.Application.start(Application.java:93)
    at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
    at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
    at org.eclipse.equinox.launcher.Main.run(Main.java:1410)

Does that already ring a bell?

1 Attachments

Discussion

  • Jan Ploski

    Jan Ploski - 2014-07-15

    No, it doesn't ring a bell. I'm also not convinced that it's EPIC-related - after all, there are no EPIC classes appearing in the quoted stack trace. Perhaps you can reduce your test case by excluding EPIC and still observe the same behavior, which would help focus your troubleshooting.

     
    • Andreas Pakulat

      Andreas Pakulat - 2014-07-15

      Well, I did try the same thing with the other script languages (and their editors) that we have in the RCP app and they all work fine. I've also found an Eclipse bugreport that suggests that even though the backtrace is coming from eclipse internals its actually caused by something in the editor implementation. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=364243.

      I'll try to reduce the testcase.

       
  • Oliver Trosien

    Oliver Trosien - 2016-05-12
    • status: open --> closed-out-of-date
     
  • Oliver Trosien

    Oliver Trosien - 2016-05-12

    cannot reproduce.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks