Upon save of editor: "Save Failed: assertion failed" #155
Comments
|
Any updates in this matter? I'm experiencing the same thing with Neon(4.6.9) and Groovy-Eclipse 2.9.2 |
|
Do you have a minimal source file that can consistently reproduce this? I have seen the editor remain unsaved because organize imports takes several seconds. This is the reason the semantic highlighting (coloring) is out of alignment. Is this happening with or without Organize Imports enabled as a save action? |
|
It happens for me without having Organize Imports among the save actions. But I do see the misaligned highlighting quite often. Have turned off all save actions for now and will see if that makes a difference. Reproducing the problem is hard, since reopening the file (losing the changes underway) or in severe cases restarting Eclipse lets me save the file again. |
|
When you get the assertion error, is the file in a complete state (fully compileable) or does it have syntax errors? The semantic highlighting happens as one of the save tasks. I'm not sure if it is synched up with any of the others, which may cause further edits or undos of edits. I have been looking into running the semantic highlight job more frequently. I have experienced the same issues you are indicating with respect to syntax coloring. |
|
Unfortunately I have not found a way of reproducing this error, but it seems as if it often occurs while writing closures both in code and javadoc. No I don't have save actions enabled but I do have the problem with the semantic highlighting and also that the content assist stops working. I would say that most of the times the problem occurs that the file doesn't have syntax errors. |
|
Hi again, Has anybody had the time to look in to this yet? |
|
Here is the code at the point of the assertion: /**
* Updates the markers managed by this annotation model by calling
* all registered marker updaters (<code>IMarkerUpdater</code>).
*
* @param document the document to which this model is currently connected
* @throws CoreException if there is a problem updating the markers
*/
public void updateMarkers(IDocument document) throws CoreException {
Assert.isTrue(fDocument == document);Up one stack frame there is: // If here, the dirty state of the editor will change to "not dirty".
// Thus, the state changing flag will be reset.
if (info.fModel instanceof AbstractMarkerAnnotationModel) {
AbstractMarkerAnnotationModel model= (AbstractMarkerAnnotationModel) info.fModel;
model.updateMarkers(document);
} |
|
Happening here too - 3rd time today (which is why I found this thread). What I'm experiencing is that the syntax highlighting is poor (often "out of date" w.r.t. the code) and problems with that seems to go hand-in-hand with a failure to display Javadoc when mouseover a method). Often, closing the editor and re-opening it fixes these issues. I can't be sure that all these issues are related, but there seems to be a significant "disconnect" between the actual file content and what is shown on screen - maybe that's the underlying cause of this "assert"? |
|
I've noticed that problems seem to be preceeded by a flood of "Unhandled event loop exception" errors. Perhaps the highlighting code is relying on being able to handle all the repercussions of one keypress before the next arrives? If the user was to cause a new change before computation for the previous had completed, the next calculation could start before the first has finished and thus, if the code isn't entirely thread-safe, "Bad Things" might happen which could lead to an internal assert failing. |
|
There is a background process for Java and Groovy that attempts to reconcile the state of the editor. The syntax coloring is a listener for this event. There is a sync flag to prevent multiple occurrences of highlighting going on. It may be that there should be a cancel so that the last one runs and you see coloring that is more aligned with your editor. If you add a single space/tab and wait a tick, the coloring should catch up. As for the assertion errors, I've seen several integrity checks related to source positions and the like. If any fails, some of the save actions barf and this stops the save process. I've tried to shore up Organize Imports. I'm not sure if you have other save actions going on. You can try to disable them all; some are inherited from your Java settings. |
|
I have no "save actions" enabled at all - everything that can be turned off is turned off. In my experience, the coloring doesn't always "catch up" - it often ends up "out of sync" and then I get the impression that the coloring/styling of the editor contents is a set of "From character X to character Y, use style Z" rules where X and Y refer to offsets within the file which were valid when the file was loaded but which have since been invalidated by changes. The only way of ensuring that the coloring "catches up" is to close and re-open the editor - merely waiting doesn't do it. |
|
So yes, semantic highlighting / syntax coloring is a JDT API where a set of ranges+styles is computed and applied. This is the same for your Java files. Usually it computes and applies so quickly that you are unaware of this. At the moment, Greclipse is having some trouble during the save process and so the highlighting is delayed or cancelled altogether. As for saving. Eclipse is an Integrated Development Environment. There are many actions that take place when a file is saved. I think what is happening is a failure in reconciliation and so Eclipse thinks it is unsafe to commit the working copy to disk. In your Eclipse preferences, do you have QuickDiff enabled? This is found under General -> Editors -> Text Editors -> Quick Diff. This appears to be the only feature that leverages the AnnotationModel. |
|
Regarding the original stack trace (included below) to save others from the redirection. The AnnotationModel is checking that its fDocument field is the same as was passed in to updateMarkers(IDocument). There are 2 possibilities here that I can see:
|
|
I did have QuickDiff enabled, yes. |
|
I disabled QuickDiff. i.e. disabling QuickDiff did not prevent the problem. |
|
Was the error you are now seeing different? These assertions failing during save are a set of problems. All must be fixed or some additional error handling must be added to stop the save from failing. |
|
The original error (bug link at the top) lists Eclipse 4.4.2. Is this what you are running on as well? |
|
I'm not using 4.4.2, I'm using "Neon.1a Release (4.6.1)". FYI the stacktrace I get (to the same depth as you quoted above) is: |
|
I have the same issue. This is my eclipse log : Message "Unhandled event loop exception" |
|
Can anyone that this is still happening for send a list of steps to recreate? That is, starting from no Eclipse at all, say what package you downloaded and what plug-ins you added and what settings you may have set in your workspace? I have not run into this after using the plug-in for quite some time in various scenarios, so I think there is an extra plug-in that you have or setting enabled that I do not. |
|
I have my suspicions regarding end-of-line codes... I'm pretty sure that this isn't exactly the same problem, but it is symptomatic of the underlying meta-data getting out of step with the file content, and if you're developing purely on Linux then you'd never see problems arising from a failure to cope with DOS line endings (on a platform where that's the default). From my p.o.v., I've got CheckStyle, CodeNarc and RTC plugins installed into a J2EE Eclipse along with the groovy support. None of those plugins should be doing anything clever "in the background" that could affect the way files are displayed but then this shouldn't be throwing asserts either... :-/ |
|
I can try and take a look. CodeNarc or something in J2EE package may be the one using the AnnoationModel. Could you try removing CodeNarc and see if this stops the exceptions? Do you use the Package Explorer or Project Explorer typically? Also, what perspective does this happen under? I use the Java and Debug perspectives pretty much exclusively. Not sure if these errors are tied to one of the J3EE perspectives. Not all refactorings are patched for Groovy and so some may run a bit oddly for Groovy sources. After you run a refactor, you can choose File > Convert Line Delimeters To > ... to get a consistent set of endings. Not exactly a fix, but can get you out of a jam if your source control is checking for consistency. |
|
My guess is that the Rational Team Concert is what is interested in the annotated model. From the demo video I see that it is collecting all source code changes made for submission as a changeset. Are you able to quickly try some of the same editing actions with a sample eclipse install that does not have RTC? |
|
I have the same kind of problems. I develop a Swing UI based on groovy and run into this problem once in an hour of developing. Very anoying is that it is not possible to copy or save the source when it happens. If you have not saved for some time, bad luck. |
|
@GerdLorscheid Could you say what your Eclipse setup is like and what types of files you are editing when this happens? Without some recreation steps, there is little I can do. |
|
Hello,
I will come back to you probably after Christmas.
Thanks
Gerd Lorscheid
Von: Eric Milles [mailto:notifications@github.com]
Gesendet: Dienstag, 20. Dezember 2016 18:10
An: groovy/groovy-eclipse <groovy-eclipse@noreply.github.com>
Cc: GerdLorscheid <gerd.lorscheid@onlinehome.de>; Mention <mention@noreply.github.com>
Betreff: Re: [groovy/groovy-eclipse] Eclipse: Upon save of editor: "Save Failed" "assertion failed:" (#155)
@GerdLorscheid <https://github.com/GerdLorscheid> Could you say what your Eclipse setup is like and what types of files you are editing when this happens? Without some recreation steps, there is little I can do.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#155 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/APK2S_q95tPkJfDnmNgMP-oGRM99MlYIks5rKAvvgaJpZM4GokD9> .
|
|
I found a reproducible sample. I don’t know whether the incomplete source code will help you but I give it a try:
At line 256 in the source file the variable evaluated needs to be defined.
So I inserted a new line at line 252
252 int evaluated
This worked ok. Then I started with the next line. Autocomplete for “RepP” worked. A new include was added for
RepPositionDef, so the line is now line 254. But autocomplete for “r.” did already not work. I typed in the property positions manually.
254 for( RepPositionDef rpd : r.positions)
I started with line 255. I tried to copy RepPositionDef from 254, but paste failed. The error already happened. I can still type in code, but I cannot copy and paste or save. When I try to save I get a white screen, which I can only close.
255 if( rpd.evaluation == RepPositionDef.NOEVAL)
So I closed and repeated the same steps with the same bad result. Now I closed, added only the first two lines and then saved the file. Saving worked and adding the third line now worked also.
As I said before adding a semicolon somewhere at the end of a statement also often helps.
I hope this gives you a hint. I wish you a happy new year.
|
|
Just upgraded STS to latest version 3.8.3.201612191259-RELEASE yesterday and started seeing this bug when editing / saving Groovy source files. I've seen this in the past so must be a regression somewhere (can't remember the problematic version combination previously, but it was stable before I upgraded..) Eclipse: With Groovy Eclipse: 2.9.2.xx-201612170628-e46 I have save actions enabled. Not sure if it's related, but I've also noticed that hitting CTRL+S when editing groovy source files (particularly larger ones with lots of imports + methods) seems to save the file but then it appears to immediately have unsaved changes again. Stack trace from workspace log: |
|
@GerdLorscheid The file seems to be missing. Can you say if the sequence of actions produces the error everytime? If you open the Groovy Event Console, do you see anything when performing these steps? Is it possible to try and break this down to a very small eclipse project and then zip and attach that? @tommyb82 I've seen the annotation model assertion failure. That is how this issue was raised. What I need is a sequence of steps to reproduce. I have not run into it myself, so I need to know if there is a common plug-in that each of you is using that is in conflict. And I would need a concrete recreation scenario. It has to be a simple Eclipse project and setup that when a list of steps are performed the exception trips. |
|
I have about 10 MB of logs in .metadata full of stack traces using the latest Neon version. So if you are interested you can tell me where to copy them.
|
|
If you could zip up your log files and send them, I'd have a look.
|
|
I had this happen locally for the first time. Looking at my Error Log, it looks like this is what started the situation off: The last line of this snippet is the line with the NPE. DocumentProvider.getDocument() is apparently never supposed to return null. The provider is supplied by the editor, however GroovyEditor does not override this in any way as far as I can tell. I'll keep trying to recreate; I have a fairly good idea of my edits just before the save failed. And see if I can tracks back to the reason the document has been disconnected from the provider. |
|
https://bugs.eclipse.org/bugs/show_bug.cgi?id=519426 submitted to Eclipse Platform UI |
|
I have copied the logs to: http://www.rchess.de/metadata-logs.zip
|
|
@GerdLorscheid Would you mind sharing a snippet of your class Repertoire. There are map entry expression errors for calcMinMax, checkFinisher, checkFinisher2 and a few others. I'd like to know what the map expression looks like in those methods. Also, there is an inner class ChangeEntry, would you mind sharing at least the class declaration line of Repertoire and ChangeEntry, including any annotations or other alterations/modifiers? |
|
Just in case it helps, I had this again today. I added 5 lines of code to an existing grails goovy controller, which was something like: I made no other changes. When I came back to the editor, the source code was gone and just the word "Error" was shown in the UI. If I then try to save the file, I get the assertion failed. so the problem happened before I tried to save. As eclipse has no local history (unlike intellij), and it doesnt seem to have any way to keep a backup of work in progress, I lost the changes. the app (grails run-app) was running at the time, but as I hadnt saved my work, it had not reloaded. |
|
I would need logs to be able to make anything of it. Also, would you be interested in an updated UI plug-in that has some extra logging in the editor so we can narrow this down?
|
|
This problem is happening more and more frequently. E.g. 10 times a day. Each time I lose all the changes I made to the file as eclipse doesnt seem to have any local history. I would try an updated plugin, but you would need to give me instrucitons on how to install it. |
|
I officially give up with eclipse for grails. I have been completely unable to add a line of code to my controllers as saving always generates this error. I am going to use notepad++ then perhaps go back to laravel as this works well in all IDEs. |
|
Since you are able to recreate the error so frequently, you present a great opportunity to find the root cause and eliminate this issue. I am creating an updated plug-in for Neon and will attach with directions. Even if you could spend a few minutes over lunch or at the end of your workday, I would very much appreciate it. I am unable to get this fixed because it has only happened to me once in 2 years.
|
|
FYI I upgraded neon2 to neon3 a week ago. I have dropped in these files. Note, I dont think the problem is with save - the error occurs before you save it, but you dont get the assertion failed until you try to save. I have a lot of UI errors happen when it goes wrong, before I hit save, e.g.
|
|
I agree, the error happens much earlier. I need to collect some info on errors or application state before the save failed to try and trace back to the root cause.
For the errors you do see, are they all the same as the latest stack trace you posted? If not, could you send me the entire log file?
|
|
What I'm looking for is when this issue occurs, can you track back to the last log entry for the editor disconnect and send me that stack trace. The ruler action NPE is the same as the save failed; asking the editor for its IDocument returns null. I need to understand why null is coming from the document provider. |
|
@PascalSchumacher I'm looking for help recreating this issue. Without that I cannot hope to fix it. Would you be able to provide some additional details or run some test patches with extra logging? |
|
@eric-milles Sorry, I personally only get the error only like once a year. I just created the issue because I closed https://issues.apache.org/jira/browse/GROOVY-7570 |
|
This error happens to me, too, whenever I work with a Groovy file for a long time. Also, I don't understand whether the fix for https://bugs.eclipse.org/bugs/show_bug.cgi?id=519426 brings any benefit and, if so, if it's the case to request a backport at least for Oxygen... |
|
Can anyone confirm this is still happening with 20171017 snapshots or later? There was a fix for JavaElement which was closing CompilationUnit buffers pre-maturely. This may have made an improvement in this area. |
|
I have 2.9.2.xx-201710180153-e47, so far works good with no issue. |
|
During the last week of work with Groovy, this has not happened to any more. I will keep on test. |
|
I've worked a lot with Greclipse recently and I never saw this problem again. Before your latest fix, this occurred 2-3 times a day. I think this can be considered fixed and possibly reopened if ever needed. |
|
Hey hi! |
|
You'll need to file a bug with Eclipse PDE. The plugin.xml is not handled by Groovy-Eclipse.
|
|
I've had this problem occur when making a GUI using SWT after I moved some code relating to creating TableItem's before the initialization of the related Table. And, since Eclipse tries auto compile GUI related code, I got a null pointer exception that I couldn't get out of (aka. mess with auto-generated code at your own risk ^^). The quick solution, copy/paste the offending file(s) to notepad and close Eclipse, reopen, paste, and try to find out what you did wrong. |
|
@NoriNoNoroi Can you open a new issue with your specific error log or stack trace and recreation steps? |
see https://issues.apache.org/jira/browse/GROOVY-7570 for details
The text was updated successfully, but these errors were encountered: