JOSM latest crashes memory problem

[dieterdreist]

After half an hour JOSM crashed with an out of memory message ("strange things may happen..."). As I had downloaded just a very small area (roughly one Z17-tile of Rome), and lots of ram (1GB), this looks like a memory hole. It happened after I wanted to upload, but there was one error (duplicate nodes) so I decided to fix that first clicking on cancel. Then it happened (or a second after, it must not be in conjunction).

18. 1391

[anonymous]

DId you assign more memory to Java or did you use standard settings? THe memory error message tells you how to increase Java memory.

[garaolaza]

I confirm this. The memory consumption has increased exponentially in the last versions (I don't update to latest everyday, so I'm not sure when). I have the feeling there is a memory leak somewhere.

I used to run JOSM with regular "java -jar josm.jar" (with about 60MB of memory) and it worked pretty well, rarely crashing and after a long time requesting WMS/Yahoo tiles. Now it happens in minutes after downloading small areas. I could work with 1GB but the editor was very slow because of memory swaping.

[xeen]

You do not have accidentally updated WMS Plugin recently? It now caches the resized images in memory making moving/drawing much faster, at the cost of doubled memory usage. Obviously, you're going to hit that 60 MB limit pretty soon (but 60 MB is /really/ low. My current memory usage is about 700 MB (without JOSM) and even my 6-year old computer had 1GB RAM, so giving JOSM 300 MB would work fine, even without swapping.

Well anyway, can you confirm that it's due to the recent WMSPlugin update? A switch that disables this additional buffer could be implemented… but if RAM is an issue, my guess is even more CPU stress won't do any good either.

[anonymous]

Probably we should have one of these "Your memory settings are very low..." requests on startup which contains such a "don't show me again" field (we have a class for this in JOSM).

[xeen]

I've found a bug in my implementation that probably causes this: When requesting images while being zoomed out and then zooming in, causes the requested images to be scaled up so actually have an "zoom in" effect.

However, if you zoom in "too much", the images sized will get incredibly large, take an incredible amount of memory. I'll see into it if we can do better than simply not storing too large images.

[dieterdreist]

Replying to xeen:

I've found a bug in my implementation that probably causes this: When requesting images while being zoomed out and then zooming in, causes the requested images to be scaled up so actually have an "zoom in" effect.

However, if you zoom in "too much", the images sized will get incredibly large, take an incredible amount of memory. I'll see into it if we can do better than simply not storing too large images.

Yes, this is exactly the issue! As posted in the original post I gave JOSM 1 GB but downloaded very small portions, it can under no circumstances have been normal memory usage. But indeed the error took place while zooming very close (the single pixels have been like 16-times size). But I wasn't actually zoomed out when requesting the wms (indicated scale on ruler roughly 10-20 m), but I definitly zoomed in "to the max", as I prefer to have good precision for the mouse.

Also I didn't have a lot of yahoo-images loaded, just a small area (few streets, maybe 200x200 m area).

[xeen]

The attached patch should fix the issue. I found that for the given test case "old" (= resize source image every time) and "new" (= resize once, then cache result) methods are about as fast, so it's no loss switching back to the old one.

Current limits are if either width or height exceeds 10 000 pixels or if width*height*3 (which is roughly the amount of memory required) exceeds the available memory. I couldn't provoke an out of memory issue whilst giving it only 100 MB to work with. This practically disables the new cache, but that's still better than making JOSM crash.

[anonymous]

Fix in 13673.

[xeen]

Apparently this problem still occurs (see #2178). I'll look into it but if you have any additional steps to reproduce, or error messages from the console (or from the error dialog) please post them!

[xeen]

I've been working for quite some time with WMS and the 63MB Java gives JOSM by default and couldn't provoke an out of memory error. Please provide steps to reproduce this or post stack traces (use "java" instead of "javaw" so you get an external console window. Copy the error message from the console if it crashes and post it here). I'll keep looking.

[dieterdreist]

can't reproduce the crash at the moment, but strange things happen anyway: memory usage went slowly (ca. half an hour) up to 1 GB (soon before crash and quite slow behaviour), but suddenly it went back to around 63 MB. Now it's again increasing (around 400 MB), but the strange thing: I did not download new data in the meantime (after it went back to 63 MB), nor did the screen change noticably (this is I still see the same WMS-Tiles, it's not that memory was free-ed because WMS-Tiles were deleted).
Now I zoomed in and out one time: +140 MB mem usage.
zoomed out a little bit: Memory from 540 MB to 767 MB
again back to almost 1 GB but then again just 600 MB.
hm, sorry, can't give you any hint what's the reason for this, but there is definitely an error somewhere.

[xeen]

The excessive jumps down are probably caused by garbage collection and nothing to worry about – what makes me wonder is why it steadily increases. That the garbage collector can clean it again means that there's a pile of unreferenced data that accumulates over time while doing nothing. I wouldn't wonder if you actually had 10x10 tiles loaded (which makes about 200 images stored in memory and 1 GB usage very likely) but apparently you only had a few tiles.

But as long as it can always go back to 63 MB… it means there are no leaks :). Or at least no very severe ones. :)