"undo" does stupid things destroying data

[Cobra]

When undoing changes to ways, josm sometimes behaves really strange. All problems seem to be related to segments, as far as I could figure out.

• some ways (newly created, so no damage/change to existing osm data - I hope so) disappeared forever when I used "undo", only the nodes still existed. "Redo" didn't bring it back. This problem occured another time with the a new way using the surviving nodes. Another way created like these ones wasn't damaged when undoing.
• segments of a few other ways were "sucked" to a node belonging to another way - some segments were connected to this node (of a newly created way unrelated to the undone changes) instead of their old nodes which were left without a way on their position.

I couldn't reproduce these problems for sure, but they did appear quite often, it seems they occur randomly.

[jttt]

What version of JOSM do you use?

[Cobra]

latest - 2292

[Daeron]

Maybe related: I just splitted a way, then undoed, but the newly created way wasn't removed and I was left with overlapping ways, the original restored version and the newly created part after the splitpoint. After that I couldn't reproduce that, although I tried with new and existing ways etc.

I'm also using the rev 2292

[malenki]

Confirm.

I had a new drawn street way (with tags) attached to an already existing way. From the existing way I removed a tag and wanted to undo that. Now the new drawn way was ripped from its nodes (the remained empty at their places). I found the existing way was dragged 6.2 km straight west and pinned to a node of a way, which node contained the 18 nodes from the newly created way and the way with all tags in between.

Very queer.

[Cobra]

Two screenshots illustrating the problem:

before the undo: ​http://home.arcor.de/SLXViper/osm/Tannheim_screwed.png

and after undo: ​http://home.arcor.de/SLXViper/osm/Tannheim_normal.png

[jttt]

Can you please test it with r2293?

[Cobra]

I did some testing but as I wrote above it is not yet known how to reproduce this. This problem didn't happen again up to now, but instead a new phenomenon showed up: I draw quite a lot of ways, tagged them, moved some of them and existing, used "undo" from time to time, etc. Then I undid all changes until the list of changes was empty - but not all data was gone.
One segment remained without visible nodes - again, this seems to be totally random as it was one in the middle (not exactly) of a way I created during this test. Neither the first nor the last, nothing special about it. I didn't even move this one.
Then I dragged the virtual node to create a new one in the middle of this segment - and all I got was this lousy NPE:

Path: trunk
URL: http://josm.openstreetmap.de/svn/trunk
Repository Root: http://josm.openstreetmap.de/svn
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Revision: 2293
Node Kind: directory
Last Changed Author: jttt
Last Changed Rev: 2293
Last Changed Date: 2009-10-17 00:56:08 +0200 (Sat, 17 Oct 2009)


Memory Usage: 57 MB / 1016 MB (40 MB allocated, but free)
Java version: 1.6.0_16

Plugins: AgPifoJ
PicLayer
measurement
openstreetbugs
openvisible
remotecontrol
usertools
utilsplugin
validator
wmsplugin
Plugin AgPifoJ Version: 17707
Plugin PicLayer Version: 17327
Plugin measurement Version: 17377
Plugin openstreetbugs Version: 18071
Plugin openvisible Version: 17536
Plugin remotecontrol Version: 17858
Plugin usertools Version: 17359
Plugin utilsplugin Version: 17707
Plugin validator Version: 18092
Plugin wmsplugin Version: 17817


java.lang.NullPointerException
	at org.openstreetmap.josm.data.osm.visitor.MapPaintVisitor.visit(MapPaintVisitor.java:189)
	at org.openstreetmap.josm.data.osm.Way.visit(Way.java:129)
	at org.openstreetmap.josm.data.osm.visitor.MapPaintVisitor.visitAll(MapPaintVisitor.java:1443)
	at org.openstreetmap.josm.gui.layer.OsmDataLayer.paint(OsmDataLayer.java:249)
	at org.openstreetmap.josm.gui.MapView.paint(MapView.java:362)
	at javax.swing.JComponent.paintChildren(JComponent.java:864)
	at javax.swing.JSplitPane.paintChildren(JSplitPane.java:1030)
	at javax.swing.JComponent.paint(JComponent.java:1038)
	at javax.swing.JComponent.paintChildren(JComponent.java:864)
	at javax.swing.JComponent.paint(JComponent.java:1038)
	at javax.swing.JComponent.paintToOffscreen(JComponent.java:5124)
	at javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:278)
	at javax.swing.RepaintManager.paint(RepaintManager.java:1220)
	at javax.swing.JComponent._paintImmediately(JComponent.java:5072)
	at javax.swing.JComponent.paintImmediately(JComponent.java:4882)
	at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:803)
	at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:714)
	at javax.swing.RepaintManager.seqPaintDirtyRegions(RepaintManager.java:694)
	at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:128)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

josm-latest 2293, /me goes and tries to reproduce at least this one

[Cobra]

oh, I forgot: after this, josm is totally unusable and no "map" is visble, only a grey area where the data should be - every action (zoom, drag) results in this NPE. Even browsing through the menus.

[Cobra]

At least the latter bug is reproducible. Create some ways, tag them, move some of them, etc. Then do a complete undo and some random segments will still be there.

looking at the .osm I saved after this one can find some ways using non-existing nodes (causing an error when trying to open it with a second instance of josm):

*snip*
  <way id='-1' visible='true'>
    <nd ref='-2' />
    <nd ref='-3' />
  </way>
  <way id='-4' visible='true'>
    <nd ref='-5' />
    <nd ref='-6' />
  </way>
*snap*

This is the only part of the file with negative ids (and refs to negative ids), the rest of it is data from the api.

You can (in the first instance of josm) add nodes to these ways and also use the virtual nodes to do so.

the .osm now looks like this:

*snip*
  <node id='-1' action='modify' visible='true' lat='47.99862630140403' lon='8.403592634332131' />
  <node id='-2' action='modify' visible='true' lat='47.998011926757975' lon='8.402242430527785' />
*snap*
*snip*
  <node id='-3' action='modify' visible='true' lat='47.99931294676239' lon='8.395167362592996' />
  <node id='-4' action='modify' visible='true' lat='47.999763685351965' lon='8.39547826581956' />
*snap*
*snip*
  <way id='-5' action='modify' visible='true'>
    <nd ref='-6' />
    <nd ref='-1' />
    <nd ref='-2' />
    <nd ref='-7' />
  </way>
  <way id='-8' action='modify' visible='true'>
    <nd ref='-9' />
    <nd ref='-4' />
    <nd ref='-3' />
    <nd ref='-10' />
*snap*

again, the rest is data from the api.

I could undo the creation of the latest node, when undoing for the second time, the NPE (same as above) is there again - and wont go away again. After ~100 NPE-warnings I just gave up and killed josm.

[jttt]

I know what's going on (WayData with incorrect node ids is loaded), but I have no luck reproducing the issue. Can you please run customized josm from ​here and send me the log? Note that there will be lot's of java.lang.Exception stacktraces, that's on purpose. But if AssertionException is shown in error dialog, that means that you run into the bug and it's good time to sent me the log.

Also the log might be quite long so redirect it to the file because otherwise parts of the log might be cut off.

[Cobra]

done. I think you need to create quite a lot of ways for this... so I did, once again in the same area where the first (and the other) problems occurred. I put some comments into the log describing what I did and what happened. The AssertionErrors were copied manually into the log after the error window popped up, since I didn't redirect stdErr as well (will do this in the future, I promise ;)). Log is attached.

[Cobra]

Log is too large for trac, so get it here: ​http://home.arcor.de/SLXViper/osm/josm-custom.log

[jttt]

Thanks. It looks like the first MARK (segment with nonexisting nodes) is the problematic part. All other strange behavior is caused by that.

At that part there was three node way and you've undo adding of the last node. It should have modified the way and remove the node from dataset. The way was correctly modified but the first two nodes of the way were removed instead of the last node.

You say in comment that there was a way with nonexisting nodes. Are you sure about that? Is it possible that only one node didn't exist?

[Cobra]

I'm definitely sure that there weren't any nodes left on this segment. It behaved like that and there weren't any nodes visible. There was only a line with a cross (virtual node) in the middle, no squares (nodes) at the ends.

[jttt]

(In [2299]) Fixed #3728 - "undo" does stupid things destroying data

[jttt]

This ticket was about two different issues - first was problem in OsmPrimitive.clearOsmId, second was about QuadBuckets.

The problem in QuadBuckets depended on edited area - for some areas and some primitives returned method QuadBuckets.get_index() -1 which later caused problem when primitive was supposed to be removed (it was not found and remained in dataset).

[anonymous]

Replying to jttt:

This ticket was about two different issues - first was problem in OsmPrimitive.clearOsmId, second was about QuadBuckets.

The problem in QuadBuckets depended on edited area - for some areas and some primitives returned method QuadBuckets.get_index() -1 which later caused problem when primitive was supposed to be removed (it was not found and remained in dataset).

It was fixed in [2299] but when was the bug introduced? It would be a good idea to add something about this to MOTD so that users can avoid the broken versions.

[jttt]

I think the bug was introduced in r2263. Snapshots 2259 is alright, 2271 is broken. In 2271 it throws NPE instead of leaving orphaned way, the NPE was probably removed later.

[anonymous]

Ticket #3735 has been marked as a duplicate of this ticket.

[malenki]

Right now with version 2300 I experienced two issues so far:

I merged two ways contained in same relations - undo deleted the ways

I added a node at a way crossing a way (meber of several relations) but deleted the node accidentially. Undo seemed to create a node in the farthest northwest with a way going there which couldn't be selected. As I drew the node again and hit undo for curiousity, the way with relations disappeared.

Errors not reproducable at afresh downloadeded objects...