Modify

Opened 9 months ago

Closed 11 days ago

#13283 closed defect (fixed)

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

Reported by: alexkemp Owned by: floscher
Priority: normal Milestone:
Component: Plugin mapillary Version: latest
Keywords: template_report Cc:

Description

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)

Attachments (2)

Data Layer 1_20170317_001700150.osm (1.1 MB) - added by alexkemp 6 weeks ago.
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.
jstack_trace.txt (55.8 KB) - added by alexkemp 5 weeks ago.
jstack trace following JOSM deadlock (no apparent cause)

Download all attachments as: .zip

Change History (17)

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

comment:2 Changed 9 months ago by Don-vip

Owner: changed from team to alexkemp
Status: newneedinfo

Can you please share your file?

Changed 6 weeks ago by 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.

comment:3 Changed 6 weeks ago by 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.

comment:4 in reply to:  3 Changed 6 weeks ago by 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.

comment:5 Changed 6 weeks ago by 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.

comment:6 Changed 6 weeks ago by 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.

comment:7 in reply to:  6 Changed 6 weeks ago by 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.

comment:8 Changed 6 weeks ago by 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

comment:9 in reply to:  8 Changed 6 weeks ago by 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...

Last edited 6 weeks ago by Don-vip (previous) (diff)

Changed 5 weeks ago by alexkemp

Attachment: jstack_trace.txt added

jstack trace following JOSM deadlock (no apparent cause)

comment:10 Changed 5 weeks ago by alexkemp

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

comment:11 Changed 5 weeks ago by Don-vip

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

comment:12 Changed 5 weeks ago by Don-vip

Owner: changed from alexkemp to team
Status: needinfonew

comment:13 Changed 5 weeks ago by Don-vip

Component: CorePlugin mapillary
Owner: changed from team to floscher

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

comment:14 Changed 11 days ago by anonymous

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

comment:15 Changed 11 days ago by floscher

Resolution: fixed
Status: newclosed

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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain floscher.
as The resolution will be set. Next status will be 'closed'.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


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

 
Note: See TracTickets for help on using tickets.