IllegalArgumentException ('Comparison method violates its general contract') while painting osm styled map (Java 7)

[positron96]

What steps will reproduce the problem?

1. Uploaded a changeset.
2. After "Uploading..." window disappeared a bug window appeared.

What is the expected result?
JOSM should be working again

What happens instead?

Please provide any additional information below. Attach a screenshot if
possible.

Repository Root: http://josm.openstreetmap.de/svn
Build-Date: 2013-04-09 01:34:26
Last Changed Author: stoecker
Revision: 5836
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
URL: http://josm.openstreetmap.de/svn/trunk
Last Changed Date: 2013-04-07 23:18:22 +0200 (Sun, 07 Apr 2013)
Last Changed Rev: 5836

Identification: JOSM/1.5 (5836 en) Windows XP
Memory Usage: 212 MB / 989 MB (76 MB allocated, but free)
Java version: 1.7.0_21, Oracle Corporation, Java HotSpot(TM) Client VM
Operating system: Windows XP
VM arguments: [-Xmx1024m]
Dataset consistency test: No problems found

Plugin: DirectDownload (29435)
Plugin: FastDraw (29457)
Plugin: SimplifyArea (29435)
Plugin: jts (29435)
Plugin: utilsplugin2 (29435)

java.lang.IllegalArgumentException: Comparison method violates its general contract!
	at java.util.ComparableTimSort.mergeLo(Unknown Source)
	at java.util.ComparableTimSort.mergeAt(Unknown Source)
	at java.util.ComparableTimSort.mergeCollapse(Unknown Source)
	at java.util.ComparableTimSort.sort(Unknown Source)
	at java.util.ComparableTimSort.sort(Unknown Source)
	at java.util.Arrays.sort(Unknown Source)
	at java.util.Collections.sort(Unknown Source)
	at org.openstreetmap.josm.data.osm.visitor.paint.StyledMapRenderer$StyleCollector.drawAll(StyledMapRenderer.java:210)
	at org.openstreetmap.josm.data.osm.visitor.paint.StyledMapRenderer.render(StyledMapRenderer.java:1394)
	at org.openstreetmap.josm.gui.layer.OsmDataLayer.paint(OsmDataLayer.java:317)
	at org.openstreetmap.josm.gui.MapView.paintLayer(MapView.java:503)
	at org.openstreetmap.josm.gui.MapView.paint(MapView.java:587)
	at javax.swing.JComponent.paintChildren(Unknown Source)
	at javax.swing.JComponent.paint(Unknown Source)
	at javax.swing.JComponent.paintChildren(Unknown Source)
	at javax.swing.JSplitPane.paintChildren(Unknown Source)
	at javax.swing.JComponent.paint(Unknown Source)
	at javax.swing.JComponent.paintChildren(Unknown Source)
	at javax.swing.JComponent.paint(Unknown Source)
	at javax.swing.JComponent.paintChildren(Unknown Source)
	at javax.swing.JComponent.paint(Unknown Source)
	at javax.swing.JComponent.paintChildren(Unknown Source)
	at javax.swing.JComponent.paint(Unknown Source)
	at javax.swing.JComponent.paintChildren(Unknown Source)
	at javax.swing.JComponent.paint(Unknown Source)
	at javax.swing.JLayeredPane.paint(Unknown Source)
	at javax.swing.JComponent.paintChildren(Unknown Source)
	at javax.swing.JComponent.paint(Unknown Source)
	at javax.swing.JComponent.paintToOffscreen(Unknown Source)
	at javax.swing.BufferStrategyPaintManager.paint(Unknown Source)
	at javax.swing.RepaintManager.paint(Unknown Source)
	at javax.swing.JComponent._paintImmediately(Unknown Source)
	at javax.swing.JComponent.paintImmediately(Unknown Source)
	at javax.swing.RepaintManager$3.run(Unknown Source)
	at javax.swing.RepaintManager$3.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
	at javax.swing.RepaintManager.paintDirtyRegions(Unknown Source)
	at javax.swing.RepaintManager.paintDirtyRegions(Unknown Source)
	at javax.swing.RepaintManager.prePaintDirtyRegions(Unknown Source)
	at javax.swing.RepaintManager.access$1000(Unknown Source)
	at javax.swing.RepaintManager$ProcessingRunnable.run(Unknown Source)
	at java.awt.event.InvocationEvent.dispatch(Unknown Source)
	at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
	at java.awt.EventQueue.access$200(Unknown Source)
	at java.awt.EventQueue$3.run(Unknown Source)
	at java.awt.EventQueue$3.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.awt.WaitDispatchSupport$2.run(Unknown Source)
	at java.awt.WaitDispatchSupport$4.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.awt.WaitDispatchSupport.enter(Unknown Source)
	at java.awt.Dialog.show(Unknown Source)
	at java.awt.Component.show(Unknown Source)
	at java.awt.Component.setVisible(Unknown Source)
	at java.awt.Window.setVisible(Unknown Source)
	at java.awt.Dialog.setVisible(Unknown Source)
	at org.openstreetmap.josm.gui.progress.PleaseWaitProgressMonitor$4.run(PleaseWaitProgressMonitor.java:170)
	at java.awt.event.InvocationEvent.dispatch(Unknown Source)
	at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
	at java.awt.EventQueue.access$200(Unknown Source)
	at java.awt.EventQueue$3.run(Unknown Source)
	at java.awt.EventQueue$3.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)

[Don-vip]

Can you please attach your .osm file and tell us:

• what map styles were enabled ?
• what is the changeset id that led to this exception ?

Thanks.

[positron96]

Replying to Don-vip:

Can you please attach your .osm file and tell us:

• what map styles were enabled ?
• what is the changeset id that led to this exception ?

Thanks.

Oh, sorry that I did not collect that info in the first place. I now do not have the osm file, which I did not keep because the upload did succeed after all. According to time, the changeset seems to be this one: ​http://www.openstreetmap.org/browse/changeset/15962970.
The map style is JOSM's default one, I never tweaked anything. Though I might had wireframe turned on, but that's unlikely. Sorry to be that uncertain, did not remember these details.

[Don-vip]

ok thanks

[Don-vip]

See #8712 to understand why this bug only occurs with JDK7.

[Don-vip]

My understanding is that StyleRecord.compareTo does not work if primitive ids change during painting, as it occurs at upload. I don't understand why we do that:

            // newer primitives to the front
            long id = this.osm.getUniqueId() - other.osm.getUniqueId();
            if (id > 0)
                return 1;
            if (id < 0)
                return -1;

What's the point of drawing new primitives first? The result would be the same, no?

[bastiK]

Replying to Don-vip:

My understanding is that StyleRecord.compareTo does not work if primitive ids change during painting, as it occurs at upload.

Yes, exactly.

I don't understand why we do that since r3836:

            // newer primitives to the front
            long id = this.osm.getUniqueId() - other.osm.getUniqueId();
            if (id > 0)
                return 1;
            if (id < 0)
                return -1;

What's the point of drawing new primitives first? The result would be the same, no?

If 0 is returned at this point, the icons overlap each other in arbitrary order. You get wild changes on the map when the styles are reloaded. The current implementation ensures a consistent map display and is also required for object-z-index to work as intended.

I guess the correct fix would be to acquire a read lock on the Dataset for the entire painting, I'll look into it.

[bastiK]

In 7107/josm:

mappaint: hold read lock on Dataset during painting, so modifications do not lead to inconsistent state (fixes #8671, see #9691)

[Don-vip]

Ok thanks that's exactly what I planned to do after you confirm me that it was necessary :)

[Don-vip]

In 7109/josm:

see #8671 - some code refactoring done in an unsuccessful attempt to reproduce error, but worth keeping

[bastiK]

Replying to Don-vip:

Ok thanks that's exactly what I planned to do after you confirm me that it was necessary :)

Yes, the main task was to figure out the real problem ...