Comment 1 Eric Moffatt 2012-09-24 14:30:02 EDT

The exception is actually coming from one of the trim bars, likely the top trim where the toolbars go. Could you check whether you get the same issue when you open other files of this type or is it only this one ?

Comment 2 Tomasz Zarna 2012-10-01 18:24:32 EDT

Got hit by the same exception, or exceptions I should say as they came in pair.

Somehow I managed to get 2 perspective switchers. To fix that I opened Window > Customize perspective and unchecked couple of tool bar items. That fixed the switchers issue, but I noticed the forementioned exceptions in the Error Log.

Comment 3 Conan Cook 2012-10-05 11:19:42 EDT

Same as Tomasz, using STS 3.0.0.  I got two Quick Access boxes, or one displayed in the middle of the top bar with other buttons either side - in both cases selecting any options in the Command Group Availability inside Customise Perspective listed nothing in the Menubar Details or Toolbar Details, even when I can see the corresponding buttons on the screen (e.g. Editor Navigation should show "Previous Edit Location" in the Toolbar Details).  The issue seems to occur when making the window larger than the default size - the various window elements don't move correctly to fit the new window size.  I'm on Windows 7.

Stack trace:

!ENTRY org.eclipse.ui 4 0 2012-10-05 16:11:23.803
!MESSAGE Unhandled event loop exception
!STACK 0
java.lang.ArithmeticException: / by zero
	at org.eclipse.e4.ui.workbench.renderers.swt.TrimBarLayout.tileLine(TrimBarLayout.java:234)
	at org.eclipse.e4.ui.workbench.renderers.swt.TrimBarLayout.layout(TrimBarLayout.java:210)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1263)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1270)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1249)
	at org.eclipse.swt.widgets.Composite.setLayoutDeferred(Composite.java:1086)
	at org.eclipse.swt.widgets.Display.runDeferredLayouts(Display.java:4193)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3751)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1022)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:916)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:585)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:540)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
	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:353)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1438)

Comment 4 Eric Moffatt 2012-10-09 13:34:04 EDT

This may be a transient effect caused by my changes to allow trim dragging. We no longer remove any trim elements so that we can 'remember' where they were in case the user moved them.

Have either of you opened a workspace saved under a later version of 4.x with an earlier version ? If so then that would be the issue, the older code *always* added the trim elements without checking if they were already there (which would now give you two of both the QA and the perspective switcher).

The NPE is likely caused by the control's implementation expecting there to be only one (likely they 'cache' the control somewhere).

If you start with a fresh window you should no longer have any issues...

Comment 5 Conan Cook 2012-10-09 13:45:40 EDT

No, it's only been in the one version of STS.  I haven't experienced the problem using vanilla Eclipse Juno.  Subjectively it seems to settle down and then come back nearer to a restart.

Comment 6 Tomasz Zarna 2012-10-09 15:29:23 EDT

(In reply to comment #4)
> Have either of you opened a workspace saved under a later version of 4.x
> with an earlier version ?

I upgraded STS several times last week, but iirc each time I picked a newer version of STS (with a newer Eclipse implicitly). I'm not 100% sure of that though.

Comment 7 Eric Moffatt 2012-10-10 13:50:39 EDT

Both of the scenarios start with an indication that the model is in an incorrect state (you shouldn't have two Search bars or Perspective Switchers). My only guess as to how to get into that state was:

1) Have a workspace and open if with an install after 2012-08-02 (that's when I changed the logic to not remove the trim on shutdown). Close it. Now the saved model has both the Search and PS in the trim.

2) Re-open it with an install *before* that date (where the code to *always add* the trim exists).

Poof ! Two Search bars / switchers.

If there's another way to induce this let me know.

If I'm correct that the exception comes only from the 'broken' model then you should simply be able to do a Window -> New Window and you should never see the issue again.

Comment 8 Christian Walther 2013-01-30 03:23:25 EST

Created attachment 226298 [details]
proposed patch

I don’t know about the double perspective switchers, but the divide by zero exception happens any time there is an even number of spacers in a trim bar, and is fixed by the attached patch.

Comment 9 Christian Walther 2013-01-30 05:46:50 EST

Created attachment 226312 [details]
proposed patch 2/2

Oops, regression: the first patch revealed another bug. The Points in curLine.sizeMap mustn’t be modified either because the TrimLine is used multiple times.

Symptom was that the search field and perspective switcher would disappear just after launch and reappear when the window was resized.

Fixed by this additional patch (to be applied on top of the first one).

This branch now has changes on the same lines as the one of my fix for bug 399458, creating conflicts when the two are merged. If preferred, I can also supply the three commits rebased onto each other (in either order), or squashed into one.

Comment 10 Christian Walther 2013-02-12 11:34:31 EST

Created attachment 226932 [details]
proposed patch 1/2

Comment 11 Christian Walther 2013-02-12 11:35:16 EST

Created attachment 226933 [details]
proposed patch 2/2

Here’s the same two commits rebased onto current master to resolve the conflict with the accepted fix for bug 399458.

Untested because I don’t have a Kepler environment at hand, but the diff is identical to what I’ve been using on the R4_2_maintenance branch.

Comment 12 Christian Walther 2013-07-03 10:44:21 EDT

I have updated my patches to Kepler (no change required) and pushed them to Gerrit:
  https://git.eclipse.org/r/14226
  https://git.eclipse.org/r/14227

(Should I squash them into a single commit? Gerrit doesn’t seem to handle topic branches consisting of multiple commits very well…)

Comment 13 Eric Moffatt 2013-07-09 15:10:17 EDT

Thanks Christian, I'll take a look at the patches fairly soon. It's quite likely that the initially corrupted state has just exposed an existing defect that we don't normally trip over...

Comment 14 Christian Walther 2013-07-10 03:41:00 EDT

Indeed. We once had such a corrupted state here too (which is why I started looking into this in the first place), but couldn’t figure out how to reproduce it. To provoke the issue for testing, I just manually edited workspace/.metadata/.plugins/org.eclipse.e4.workbench/workbench.xmi, duplicating the PerspectiveSpacer element.

(For others reading, it may be worth noting again that my patches only address the divide by zero exception that is caused by the even number of spacers in the corrupted state, not how the corrupted state itself came about. There may however be legitimate, non-corrupted reasons to have an even number of spacers in a trim bar.)

Comment 15 Eric Moffatt 2013-07-24 10:11:39 EDT

Chrisian, I'm having trouble reproducing the DivByZero...I've already added code that duplicates the "PerspectiveSpacer" as you suggest but my layout appears to be working normally (without the patch).

Could you do a couple of things ?

Check to see if it's still an issue. If so could you attach the workbench.xmi that leads to the issue.

Thanks.

Comment 16 Eric Moffatt 2013-07-24 11:44:29 EDT

Committed to the R4_3_maintenance Stream

http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R4_3_maintenance&id=dd68cf45ed0250176e8d16b7e927c9f9105eaef6

Christian, I've only committed the code in the 14226 patch. I think the rest of the code is OK since it doesn't modify any other values in 'curLine', do you agree ?

Comment 17 Eric Moffatt 2013-07-24 12:20:33 EDT

Marking FIXED.

Comment 18 Eric Moffatt 2013-07-25 11:11:34 EDT

Ok then...we *do* need the second patch. While testing I found a startup issue where the initial layout was wrong. Applying the 14227 patch does indeed seem to fix the issue, thanks again...

Comment 19 Christian Walther 2013-07-25 11:20:08 EDT

Hi Eric, I'm glad you're figuring it all out on your own :) Sorry, I'm swamped with work, but I should be able to take a look at what you're doing within a few days. May take until next week though. Thanks for your work.

Comment 20 Eric Moffatt 2013-07-25 11:35:14 EDT

Amended the previous commit to include the second part of the patch. This fixes a problem with the initial layout of restarted sessions.

http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R4_3_maintenance&id=2fdf604448009727b818987b0f0684abe8c4bc22

Comment 21 Eric Moffatt 2013-07-25 11:36:32 EDT

Christian, don't thank me dude, thank yourself...the code's much better now !

Comment 22 Christian Walther 2013-07-29 09:37:18 EDT

Verified that the issue still existed and is fixed by the two accepted commits in R4_3_maintenance (haven’t checked master as I don’t currently have a Luna setup). Thanks! (To myself. Or whomever. ;))

I looks like you’ve been able to reproduce it now and don’t need my hacked workbench.xmi anymore?

The symptom without the second patch was described in comment #9. I assume that’s the same “initial layout issue” as you saw.

Out of curiosity, what was the reason for duplicating this as bug #413662, is there anything that requires separate bugzilla entries for the maintenance and master branches or something?

Comment 23 Paul Webster 2013-07-29 10:12:08 EDT

(In reply to comment #22)
> Out of curiosity, what was the reason for duplicating this as bug #413662,
> is there anything that requires separate bugzilla entries for the
> maintenance and master branches or something?

We dup the bug so that we have a record of which streams the fix needs to be verified in (a record of each change we've committed).  In this case, 4.3.1 and 4.4 M1.

PW