Opened 15 years ago
Closed 15 years ago
#3728 closed defect (fixed)
"undo" does stupid things destroying data
Reported by: | Cobra | Owned by: | team |
---|---|---|---|
Priority: | blocker | Milestone: | |
Component: | Core | Version: | latest |
Keywords: | Cc: | nakor.wp@… |
Description
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.
Attachments (0)
Change History (22)
comment:1 by , 15 years ago
comment:3 by , 15 years ago
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
comment:4 by , 15 years ago
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.
comment:5 by , 15 years ago
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
comment:6 by , 15 years ago
Cc: | added |
---|
comment:8 by , 15 years ago
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
comment:9 by , 15 years ago
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.
comment:10 by , 15 years ago
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.
comment:11 by , 15 years ago
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.
comment:12 by , 15 years ago
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.
comment:13 by , 15 years ago
Log is too large for trac, so get it here: http://home.arcor.de/SLXViper/osm/josm-custom.log
comment:14 by , 15 years ago
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?
comment:15 by , 15 years ago
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.
comment:16 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
follow-up: 18 comment:17 by , 15 years ago
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).
comment:18 by , 15 years ago
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.
comment:19 by , 15 years ago
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.
comment:21 by , 15 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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...
comment:22 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
What version of JOSM do you use?