Modify

Opened 9 years ago

Closed 8 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 Changed 9 years ago by jttt

What version of JOSM do you use?

comment:2 Changed 9 years ago by Cobra

latest - 2292

comment:3 Changed 9 years ago by 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

comment:4 Changed 9 years ago by 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.

comment:5 Changed 9 years ago by 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

comment:6 Changed 9 years ago by Nakor

Cc: nakor.wp@… added

comment:7 Changed 9 years ago by jttt

Can you please test it with r2293?

comment:8 Changed 9 years ago by 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

comment:9 Changed 9 years ago by 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.

comment:10 Changed 9 years ago by 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.

comment:11 Changed 9 years ago by 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.

comment:12 Changed 9 years ago by 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.

comment:13 Changed 9 years ago by Cobra

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

comment:14 Changed 9 years ago by 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?

comment:15 Changed 9 years ago by 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.

comment:16 Changed 9 years ago by jttt

Resolution: fixed
Status: newclosed

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

comment:17 Changed 9 years ago by 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).

comment:18 in reply to:  17 Changed 9 years ago by 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.

comment:19 Changed 9 years ago by 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.

comment:20 Changed 9 years ago by anonymous

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

comment:21 Changed 9 years ago by malenki

Resolution: fixed
Status: closedreopened

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 Changed 8 years ago by stoecker

Resolution: fixed
Status: reopenedclosed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.