Loading an OSM file causes cpu load to hit 100%, permanently

[alexkemp]

What steps will reproduce the problem?

1. Load latest snapshot + update plugins
2. Load saved .osm file (newark_sherwood.osm 64.9 MB (64,891,585 bytes))
3. Attempt to navigate to a BoundaryLine, and watch as load increases to 100%

What is the expected result?

Able to edit in normal fashion

What happens instead?

The only way to exit was to press on/off switch on box (just like using WinXP all over again)

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

Sorry, but in the circumstances it is impossible to provide any further info, other than I recently loaded a 500+MB OSM-file & the system worked, just slowly. However, that was with 'tested', not 'latest'.

URL:http://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2016-08-04 23:55:20 +0200 (Thu, 04 Aug 2016)
Build-Date:2016-08-05 01:35:41
Revision:10733
Relative:URL: ^/trunk

Identification: JOSM/1.5 (10733 en_GB) Linux Debian GNU/Linux 8.5 (jessie)
Memory Usage: 314 MB / 1636 MB (224 MB allocated, but free)
Java version: 1.8.0_91-8u91-b14-1~bpo8+1-b14, Oracle Corporation, OpenJDK 64-Bit Server VM
Java package: openjdk-8-jre:amd64-8u91-b14-1~bpo8+1
VM arguments: [-Djosm.restart=true, -Djosm.home=<josm.pref>, -Djava.net.useSystemProxies=true]

Plugins:
+ DirectUpload (32329)
+ Mapillary (32639)
+ apache-commons (32584)
+ apache-http (32584)
+ buildings_tools (32728)
+ continuosDownload (53)
+ terracer (32426)

[alexkemp]

It seems nothing to do explicitly with JOSM-latest as JOSM-tested just gave me almost identical behaviour with the same file. I acted immediately to 'ps aux ...' + kill -9 ...' & exited JOSM without having to use the on/off switch. Sorry for a peremptory report.

[Don-vip]

Can you please share your file?

[alexkemp]

JOSM auto-save file used to recover following system freeze; JOSM immediately took all 4 CPU cores to 100%; "kill -9 ps-JOSM" required to get working system back.

[alexkemp]

I was going to add a comment to one of my "My system froze for an unknown reason" tickets then discovered this ticket, so will put it here.

1. It is unlikely that Mapillary is the reason for the system freeze. After update/load JOSM then add Mapillary I waved the cursor over various Map nodes without any problem.
2. It took a good long time on this occasion before JOSM peremptorily froze.
3. Agreeing to auto-load the last saved-file on restart immediately caused 100% load on all 4 cores. System rapidly degraded towards a full-stop, but I managed to get the terminal loaded in time.
4. JOSM refused to die with a normal "kill ps-id" & I needed to use a silver bullet to kill it on this occasion.
5. The attached file is the latest auto-save file within "~/.josm-latest/autosave/deleted_layers/" ('Data Layer 1_20170317_001700150.osm') and, hopefully, is the same file that I loaded (the next older file is dated Sunday 2017-03-12).
6. I just tried that file with the so-called JOSM-stable & had exactly the same problem, and had to kill it in the same way.
7. Note that I have learned to switch the autoload plugin OFF in these circumstances, so that was NOT a contributor to the load.
8. Bugger. Fix this one, please.

PS
The routine to continuously backup to .osm file is a brilliant idea. What a shame that it is required so often.

[Don-vip]

Replying to alexkemp:

I was going to add a comment to one of my "My system froze for an unknown reason" tickets

Please stop this and answer my question in 14517#comment:2. It's clear that ATK Java wrapper is at fault here and you must find a way to update or disable it. Blaming JOSM developers will not help you.

[alexkemp]

Who exactly is blaming who?

I'm attempting to help by reporting a serious bug with as much information as I can manage in the place where - in my ignorance - it may best be placed. I'm blaming nobody for nothing. I'm just reporting a bug.

[alexkemp]

I update my system daily. The presumption on ATK Java Wrapper being at fault appears to be erroneous (below).

Having finally followed & read the link to https://josm.openstreetmap.de/ticket/14517#comment:2 then https://josm.openstreetmap.de/ticket/12022#comment:40 I find it already to be switched off. These are the results found on my system. What is reported below is clean & untouched by myself.

~$ ls -Al /etc/java-8-openjdk/accessibility.properties
-rw-r--r-- 1 root root 391 Mar 17 2015 /etc/java-8-openjdk/accessibility.properties
~$ cat /etc/java-8-openjdk/accessibility.properties
#
# The following line specifies the assistive technology classes
# that should be loaded into the Java VM when the AWT is initailized.
# Specify multiple classes by separating them with commas.
# Note: the line below cannot end the file (there must be at
# a minimum a blank line following it).
#
# Doesn't work, see LP: #935296
#assistive_technologies=org.GNOME.Accessibility.AtkWrapper

Think again.

PS
I assume that I am not getting some emails, as the links above are new for me.

[Don-vip]

Replying to alexkemp:

I update my system daily.

Yes but you won't get the ATK wrapper update which fixes its severe bug before the next stable version of Debian is released, it can take quite some time. I was thinking about a manual update to see if it resolves the situation.

The presumption on ATK Java Wrapper being at fault appears to be erroneous (below).

Indeed it seems to be disabled. Not sure if it could still be loaded by some other mechanism I don't know about. I'm not 100% convinced it is not the root cause as you have a very buggy version and the symptoms you experience are consistent with all the bug reports that were caused by this software.

Could you please try to get the JVM stacktraces with jstack or kill -3 when it happens? We will need this to investigate.

[alexkemp]

Could you please try to get the JVM stacktraces with jstack or kill -3 when it happens?

There were 8 months between those two similar faults. We may be waiting some time for the next one. However, jstack is already in the system.

You may be interested in this (so, java-6/7/8 all have the same setting):-

~$ cat /usr/share/doc/libatk-wrapper-java/README.Debian
Accessibility is disabled in openjdk by default.  This is because it breaks some
applications, notably non-threaded ones.  To re-enable it (which will probably
break some applications, in /etc/java-6-openjdk/accessibility.properties
uncomment

assistive_technologies=org.GNOME.Accessibility.AtkWrapper

Current + latest libatk-wrapper-java are each 0.30.5-1

[Don-vip]

Replying to alexkemp:

You may be interested in this (so, java-6/7/8 all have the same setting):-

~$ cat /usr/share/doc/libatk-wrapper-java/README.Debian
Accessibility is disabled in openjdk by default.

This was true when java 6 was the default. But at some point in time Java Debian maintainers thought it would be a good idea to enable it in openjdk-8 and then we started to get dozens of strange bug reports. It took us several months to spot the root cause and we asked to disable it again as there was little hope to see this bug fixed quickly. After our request someone stepped up to fix the issue, and the versions >= 0.33.3-6 seem to work fine. The correct version has shipped with Ubuntu 16.10 and since, the number of bug reports dropped to nearly 0. Only people using Debian stable are currently affected AFAIK. Complete history in the 70+ comments of #12022 and all its duplicates...

[alexkemp]

jstack trace following JOSM deadlock (no apparent cause)

[alexkemp]

Same jstack trace added here as to #12022 (latter was where my earlier reports on unexplained freeze were added as duplicates).

[Don-vip]

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

[Don-vip]

All 4 blocked threads are from Mapillary plugin, not a core defect.

[anonymous]

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

[floscher]

I worked on this issue and it seems to be fixed now in v1.5.1+. So I'll close this for now. If you still encounter this, feel free to reopen.