Very Rare Relation Editing Display Code Bug

[ezekielf@…]

What steps will reproduce the problem?

1. download a relation (Ive experienced this with multipolygons)
2. open edit relation window
3. attempt to re-order relation members

What is the expected result?
I should be able to re-order relation members

What happens instead?
I get an error saying something like "an unexpected error has occured, this is always a coding error, please file a bug report"

I'm marking this "Major" because I've created a bunch of fairly complex multipolygon relations using Potlach. They render fine in Mapnik, but are completely screwed up in Osmarender. I believe the problem is that Potlach doesn't allow you to specify an order for the relation members and Osmarender needs that order to render them properly even though Mapnik doesn't. I'm attempting to make them render properly in osmarender by re-ordering the members in JOSM, but this bug is blocking me from doing that. Clearly the order doesn't matter to Mapnik. If this were true of all renderers then this would not be an issue, but that's beyond the scope of this bug report….

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

Repository Root: http://josm.openstreetmap.de/svn
Build-Date: 2010-06-11 01:31:34
Last Changed Author: stoecker
Revision: 3329
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
URL: http://josm.openstreetmap.de/svn/trunk
Last Changed Date: 2010-06-10 09:53:42 +0200 (Thu, 10 Jun 2010)
Last Changed Rev: 3329

Identification: JOSM/1.5 (3329 en)
Memory Usage: 102 MB / 123 MB (16 MB allocated, but free)
Java version: 1.6.0_20, Apple Inc., Java HotSpot(TM) 64-Bit Server VM
Operating system: Mac OS X
Dataset consistency test: No problems found


java.lang.NullPointerException
	at org.openstreetmap.josm.gui.dialogs.relation.MemberTableMemberCellRenderer.renderPrimitive(MemberTableMemberCellRenderer.java:19)
	at org.openstreetmap.josm.gui.dialogs.relation.MemberTableMemberCellRenderer.getTableCellRendererComponent(MemberTableMemberCellRenderer.java:33)
	at javax.swing.JTable$AccessibleJTable.getAccessibleChild(JTable.java:7023)
	at javax.swing.JTable$AccessibleJTable.getAccessibleAt(JTable.java:7410)
	at javax.swing.JTable$AccessibleJTable.valueChanged(JTable.java:6923)
	at javax.swing.DefaultListSelectionModel.fireValueChanged(DefaultListSelectionModel.java:167)
	at javax.swing.DefaultListSelectionModel.fireValueChanged(DefaultListSelectionModel.java:147)
	at javax.swing.DefaultListSelectionModel.fireValueChanged(DefaultListSelectionModel.java:194)
	at javax.swing.DefaultListSelectionModel.changeSelection(DefaultListSelectionModel.java:388)
	at javax.swing.DefaultListSelectionModel.changeSelection(DefaultListSelectionModel.java:398)
	at javax.swing.DefaultListSelectionModel.removeSelectionIntervalImpl(DefaultListSelectionModel.java:559)
	at javax.swing.DefaultListSelectionModel.clearSelection(DefaultListSelectionModel.java:403)
	at javax.swing.JTable.clearSelection(JTable.java:2080)
	at javax.swing.JTable.clearSelectionAndLeadAnchor(JTable.java:2088)
	at javax.swing.JTable.tableChanged(JTable.java:4433)
	at javax.swing.table.AbstractTableModel.fireTableChanged(AbstractTableModel.java:280)
	at javax.swing.table.AbstractTableModel.fireTableDataChanged(AbstractTableModel.java:182)
	at org.openstreetmap.josm.gui.dialogs.relation.MemberTableModel.moveUp(MemberTableModel.java:212)
	at org.openstreetmap.josm.gui.dialogs.relation.GenericRelationEditor$MoveUpAction.actionPerformed(GenericRelationEditor.java:936)
	at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2028)
	at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2351)
	at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
	at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
	at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:236)
	at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:272)
	at java.awt.Component.processMouseEvent(Component.java:6348)
	at javax.swing.JComponent.processMouseEvent(JComponent.java:3267)
	at java.awt.Component.processEvent(Component.java:6113)
	at java.awt.Container.processEvent(Container.java:2085)
	at java.awt.Component.dispatchEventImpl(Component.java:4714)
	at java.awt.Container.dispatchEventImpl(Container.java:2143)
	at java.awt.Component.dispatchEvent(Component.java:4544)
	at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4618)
	at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4282)
	at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4212)
	at java.awt.Container.dispatchEventImpl(Container.java:2129)
	at java.awt.Window.dispatchEventImpl(Window.java:2478)
	at java.awt.Component.dispatchEvent(Component.java:4544)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:635)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:296)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:211)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:201)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:196)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:188)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

[ezekielf@…]

Screen Shot of Error Message

[stoecker]

Please make this reproducable. Which relation? What needs to be done before?

[ezekielf@…]

Ok. I just tested this relation: ​http://www.openstreetmap.org/browse/relation/960288 and the bug occurred. It happens with every relation I've tried though. Here are the steps I took:

1. Open JOSM
2. download some data
3. select a member way of a relation
4. open edit relation window
5. select a member way
6. click the "move up" or "move down" button
7. at this point the error dialog pops up
8. after the dialog has been dismissed it will continue to be triggered by simply clicking anywhere in the edit relation window

I've experienced this in version 3329 using the web start, and in 3208 which I have downloaded. I'm using Mac OS X 10.6.3 and it looks like I've got Java 6 (13.2.0) installed. Doesn't look like I have any JOSM plugins installed either. What other information can I give you to make this reproducible? Could it have something to do with the fact that the relations were originally created by Potlatch?

[ezekielf@…]

I also just tried creating a relation from scratch in JOSM and got the same error. I clicked the created new relation button, entered key=type and value=multipolygon, pressed tab, and then the error popped up. Clicking the add tag button made it pop up again.

[stoecker]

Can't reproduce here. Does this also happen when you have no data loaded (i.e. start a new layer, create an element and make the relation with it)?

What happens if you delete (or temporary rename) your josm preferences and start from scratch?

[anonymous]

I've renamed my JOSM preferences and tried working with no data loaded. Same results.

With more perseverance I have actually been able to re-order relation members it's just extremely frustrating because every time I click the move up or down button a dialog box pops up telling me "An unexpected exception has occurred. This is always a coding error". Even though this error occurs, the relation members do move up or down in the list. Re-ordering relation members is just one of the times when this error pops up. It also happens when performing a variety of other actions with relations. In most cases it seems that I am able to complete the action but only after dismissing the error. It often prompts me 2-3 times in rapid succession. Makes it very time consuming and annoying to work with relations at all in JOSM. Lately I've been drawing ways in JOSM uploading them to the server and then creating the relations in Potlatch.

I'm sorry I haven't been able to help you reproduce this. Is there anything else I can test? Would a screencast of it happening be helpful?

[ezekielf@…]

forgot to put my email in. The above anonymous comment is from me.

[stoecker]

The error happens in the display code, so your oberservations are explainable. But actually I can't find a reason why in this display code there should be an null pointer exception. As you describe it it would be very annoying and if it is a common problem we would have much more reports for it. So I assume either you have something special which triggers a bug in josm or your installation is somehow broken (i.e. a bug in Java or your system).

In the second case probably reinstalling Java could help. In the first case I would need to find this which is special for you and fix it. Thought this is very hard without a possibility to reproduce it.

BTW: Did you try updating josm to the current version?

Could you try another Look&Feel in the settings? Maybe it is related to a special GUI variant of Java.

Actually your screenshot hidens the table itself. At least one element must be wrong (no text, no icon, ...). Which one? Is it always the same?

[bastiK]

Maybe has something to do with AccessibleJTable.getAccessibleChild?

When I dump the Stack at MemberTableMemberCellRenderer.java:19 I don't get a stack trace like this. For me there are repaint events, only.

[ezekielf@…]

javatester.org tells me I have "Java Version: 1.6.0_20 from Apple Inc". From a bit of googling it seems that there is no way to re-install Java without re-installing Mac OS X. I'd really rather not do that. I am currently using JOSM 3376 and all my lastest testing has been with that. I've tried each of the four Look&Feel settings (Metal, Nimbus, CDE/Motif, and Mac OS X) with the same results so it doesn't seem to be related to that.

Stoeker, I don't understand what you are saying here:
"Actually your screenshot hidens the table itself. At least one element must be wrong (no text, no icon, ...). Which one? Is it always the same?"
Perhaps you can clarify so I can provide an answer?

Thanks for trying to get to the bottom of this. I appreciate it.

-Zeke

[stoecker]

The bug appears in the draw code of the down left table (the member table). So when you click the bug away, there should be distortions in this table (one error in one field for each exception you have seen and clicked away). Maybe the distribution of these helps to find an issue. I.e. if it is always the first or last or the one above or below the moved element, ... Also the column may indicate the problem.

Although it may be a Java problem it sounds like such a special case issue which is hard to track down and I like to have these fixed when possible. Even if I'm not affected now, these beast tend to come back sooner or later.

[ezekielf@…]

Ok, I've looked for distortions in the member table after the error box shows up, but I'm not seeing them. Maybe I'm just not familiar enough with how JOSM should behave. I've made a screen recording of the error happening on my MacBook. You can watch it here: ​http://www.youtube.com/watch?v=-Z7kDt2Qr_0 As you can see it happens very often.

I also installed JOSM on a different Mac (a Mac Mini) and tried to reproduce the error. It did not happen. So it seems to be something very specific to my Macbook's system. They both have the latest Mac OS X (10.6.4) and the latest version of Java (1.6.0_20). They do have lots of different software installed. Could this somehow be caused by a third party application that is installed on the MacBook, but not the Mac Mini?

Zeke

[anonymous]

Ok I've narrowed things down a bit more. I've failed to reproduce the error on a second user account on my MacBook and I've also failed to reproduce the error on the main user account with no other applications running and no 3rd-party background processes running (Evernote helper, Vmware Fusion helper, X-Marks for Safari, etc). Given that the error did not occur under those conditions it seems we're dealing with a conflict with some other piece of software here. When I have more time I will attempt to figure out which of the processes I normally have running is causing JOSM to behave this way and report back.

Zeke

[ezekielf@…]

I think I've discovered the conflicting software. I use a little window resizing utility called Cinch ( ​http://www.irradiatedsoftware.com/cinch/ ). The errors occur when it is running and they do not occur when it is not. I have no idea why this would be, but at least I have a way to make the errors stop now. This will make working with relations much easier! I'll just quit Cinch before using JOSM.

Now that I've pinpointed the conditions, hopefully someone can download Cinch and see if there is or is not a small bug worth fixing in JOSM. I suppose these exceptions may be caused by some of Cinch's code so I'm going to file a bug report with the developer of Cinch so he can have a look too. Thanks for all the help.

[anonymous]

I have an open bug with Apple to get this issue addressed. The issue is inside Apple's implementation of Accessibility for Java and the way Java apps are using it. There are many Java apps that exhibit weird behavior when being interacted with via Accessibility (OpenOffice, NetBeans, etc).

[bastiK]

Good luck with this one, I don't see it fixed any time soon. :)

[ezekielf@…]

Thanks, I'm just happy to have gotten to the bottom of it as now I can avoid the issue.