Community
Participate
Working Groups
Created attachment 235213 [details] workbench.xmi file that loads with no children windows When attempting to restore the previous workbench state, the attached workbench.xmi file parses without errors, but the MApplication/ApplicationImpl object that is created contains a null "children" field. As a result, PartRenderingEngine.run() never calls createGui(), so Eclipse immediately exits (with a slew of error messages from early startup plug-ins that expect the workbench to have been created). I'm not sure if this is a case of corrupted model data or just a bug in serializing it back in from the workbench.xmi file, but as a fallback for any serialization problems, ResourceHandler. loadMostRecentModel() (near line 206) can check not only for whether the resource loading returned null, but also whether the returned resource has a valid MApplication. If the MApplication is not valid, it could fall back to loading from the application definition instance, and log the problem.
Ping. Does validating the reloaded workbench state and discarding it if it is invalid seem reasonable?
Is there something in the .log? Bug 410273 looks related.
Created attachment 235390 [details] Log file for when attempting to load the workbench.xmi file
The two bugs do not appear to be related. The workbench.xmi file attached to that bug contains a top-level "<children xsi:type="basic:TrimmedWindow"...>" tag, which for some reason is missing from the workbench.xmi file attached to this bug. I don't have any additional information as to what state Eclipse was in when it failed to properly serialize out the children windows, so I guess this bug can only address more graceful recovery when such a problem occurs.
(In reply to Terry Parker from comment #4) Another option would be to add asserts and/or logging to the code that writes to workbench.xmi to get closer to the root cause of the problem.
To make it more interesting, eclipse is supposed to support a headless workbench (no child windows). PW
See Bug 323075 for headless mode.
(In reply to Terry Parker from comment #1) > Ping. Does validating the reloaded workbench state and discarding it if it > is invalid seem reasonable? Yes. Could you provide a Gerrit review for it?
(In reply to Lars Vogel from comment #8) > (In reply to Terry Parker from comment #1) > > Ping. Does validating the reloaded workbench state and discarding it if it > > is invalid seem reasonable? > > Yes. Could you provide a Gerrit review for it? Done. https://git.eclipse.org/r/#/c/25853
Committed: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=e37da30b63cdd33dcf30eb6a5be12657b14a6fd0 As I commented on Gerrit..."Belt *and* suspenders, nice"...Thanks Terry ! BTW, Paul's going to add some guard code to trap whenever we get into this state in case it ever happens again so we can figure out why...
Log when it happens: https://git.eclipse.org/r/26298 Eric, could you please review this? PW
Committed: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=47f11c69bdb654009053bd19d70c54b8b6d908ca Only nit is that we don't unsubscribe the event but I realize that the Workbench's lifecycle matches that of the app...
Could this also be the fix to Bug 381555?
(In reply to Paul Benedict from comment #13) > Could this also be the fix to Bug 381555? This can probably help with bug 381555, but it's not addressing the underlying cause, it's just trying to prevent a model with no windows from being saved and a model with no windows from killing the startup. But if the model has even one window, it won't guard against anything in it that's corrupt or suspect. PW
Verified in I20140511-2000.
*** Bug 418328 has been marked as a duplicate of this bug. ***
*** Bug 433750 has been marked as a duplicate of this bug. ***
(In reply to Eric Moffatt from comment #10) > Committed: > > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=e37da30b63cdd33dcf30eb6a5be12657b14a6fd0 > > As I commented on Gerrit..."Belt *and* suspenders, nice"...Thanks Terry ! > > BTW, Paul's going to add some guard code to trap whenever we get into this > state in case it ever happens again so we can figure out why... This commit got in a regression - see https://bugs.eclipse.org/bugs/show_bug.cgi?id=463125
This fix has been backported, see bug 482162 comment 5.
