Community
Participate
Working Groups
4.7.0.I20170208-2000: !MESSAGE An internal error occurred during: "Searching for markers". !STACK 0 java.lang.IllegalArgumentException: Comparison method violates its general contract! at java.util.TimSort.mergeHi(TimSort.java:899) at java.util.TimSort.mergeAt(TimSort.java:516) at java.util.TimSort.mergeCollapse(TimSort.java:441) at java.util.TimSort.sort(TimSort.java:245) at java.util.Arrays.sort(Arrays.java:1512) at org.eclipse.ui.internal.views.markers.MarkerSortUtil.sortStartingKElement(MarkerSortUtil.java:326) at org.eclipse.ui.internal.views.markers.Markers.sortMarkerEntries(Markers.java:160) at org.eclipse.ui.internal.views.markers.Markers.sortAndMakeCategories(Markers.java:133) at org.eclipse.ui.internal.views.markers.Markers.updateWithNewMarkers(Markers.java:97) at org.eclipse.ui.internal.views.markers.MarkerUpdateJob.processMarkerEntries(MarkerUpdateJob.java:125) at org.eclipse.ui.internal.views.markers.MarkerUpdateJob.buildMarkers(MarkerUpdateJob.java:79) at org.eclipse.ui.internal.views.markers.MarkerUpdateJob.run(MarkerUpdateJob.java:51) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
The root cause is that MarkerComparator violates its general contract: the repeated invocation of compare() with same arguments can return different results, because the MarkerComparator depends on mutable internal AND external state during comparison. While performing Problems view update, MarkerUpdateJob (running in background thread) will fail if the MarkerComparator compare algorithm changes, because MarkerUpdateJob sorts the Problems view entries using MarkerComparator. MarkerComparator.compare() uses compareCategory() and compareFields(). compareCategory() is unstable and depends on external state because it uses org.eclipse.ui.views.markers.MarkerField.compare(MarkerItem, MarkerItem) method, which (in at least one implementation I found) uses mutable markers model to compute results. E.g. if marker was deleted during sort, but MarkerItem still contains the reference to it, TypeMarkerField.getValue() will return marker type id at the begin of the sort and "Other" after deletion of the marker. compareFields() is unstable and depends on internal state because both "descendingFields" and "fields" fields which are used in compareFields() are mutable via setPrimarySortField(). To reproduce the later case (have not tried yet, but this is the most likely from looking at code): constantly change some resource with some background job and at same time constantly click on different column headers in the Problems view.
*** Bug 468234 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 371586 ***