completely stall of program

[skyper]

What steps will reproduce the problem?

Simple editing with mapillary layer active.

What is the expected result?

Normal run of the program.

What happens instead?

completely stall of program

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

Do not exactly know what causes this problem but I blame either mapillary or download mechanism of imagery, as it did only a cure so far with an active mapillary layer and once after enabling Bing and the connection broke before the attribution was downloaded.

URL:https://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2019-07-23 21:47:40 +0200 (Tue, 23 Jul 2019)
Build-Date:2019-07-24 01:30:51
Revision:15262
Relative:URL: ^/trunk

Plugins:
+ ElevationProfile (35066)
+ ImportImagePlugin (34908)
+ Mapillary (1.5.18)
+ apache-commons (34908)
+ apache-http (34908)
+ ejml (35049)
+ geotools (34908)
+ imagery_offset_db (34908)
+ jaxb (35014)
+ jna (34908)
+ jts (35064)
+ log4j (34908)
+ opendata (34997)
+ reverter (34999)
+ tag2link (35070)
+ undelete (34977)
+ utilsplugin2 (34977)

Do not get through the spam filter with console output and dump (too many links). Gonna attach them.

[skyper]

console log and dump (hope I get through spam filter)

[skyper]

...
2019-07-26 16:57:32.681 INFO: GET https://api.openstreetmap.org/api/0.6/user/details (get number of unread messages) -> HTTP_1 200 (462 B)
2019-07-26 17:02:32.705 INFO: GET https://api.openstreetmap.org/api/0.6/user/details (get number of unread messages) -> HTTP_1 200 (462 B)

Oh maybe it is only the unread messages task. Remember that I had problems with it years ago.

[naoliv]

Maybe the problem is on this blocked thread?

"pool-4-thread-2" #1594 prio=5 os_prio=0 tid=0x00007f25980f9000 nid=0x3925 waiting for monitor entry [0x00007f258962c000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at java.awt.Component.enable(Component.java:1488)
        - waiting to lock <0x00000000ce82e5c0> (a java.awt.Component$AWTTreeLock)
        at javax.swing.JComponent.enable(JComponent.java:3623)
        at java.awt.Component.enable(Component.java:1513)
        at java.awt.Component.setEnabled(Component.java:1478)
        at javax.swing.JComponent.setEnabled(JComponent.java:2680)
        at javax.swing.AbstractButton.setEnabled(AbstractButton.java:2091)
        at org.openstreetmap.josm.gui.SideButton.setEnabled(SideButton.java:114)
        at org.openstreetmap.josm.plugins.mapillary.MapillaryLayer.updateNearestImages(MapillaryLayer.java:538)
        - locked <0x00000000dcfc77a8> (a org.openstreetmap.josm.plugins.mapillary.MapillaryLayer)
        at org.openstreetmap.josm.plugins.mapillary.MapillaryLayer.imagesAdded(MapillaryLayer.java:491)
        at org.openstreetmap.josm.plugins.mapillary.MapillaryData$$Lambda$919/551601625.accept(Unknown Source)
        at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
        at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
        at java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
        at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
        at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
        at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
        at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
        at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
        at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
        at org.openstreetmap.josm.plugins.mapillary.MapillaryData.fireImagesAdded(MapillaryData.java:246)
        at org.openstreetmap.josm.plugins.mapillary.MapillaryData.addAll(MapillaryData.java:115)
        at org.openstreetmap.josm.plugins.mapillary.io.download.SequenceDownloadRunnable.run(SequenceDownloadRunnable.java:63)
        at org.openstreetmap.josm.plugins.mapillary.io.download.BoundsDownloadRunnable.run(BoundsDownloadRunnable.java:38)
        at org.openstreetmap.josm.plugins.mapillary.io.download.MapillarySquareDownloadRunnable.run(MapillarySquareDownloadRunnable.java:32)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

[skyper]

#17864 seems to be similar.

[richlv]

This seems to be terribly easy to trigger lately. With automatic Mapillary image download enabled, I'm unable to pan the map view without getting a hang very soon.

[Don-vip]

@richlv @naoliv @skyper do you still have this issue with Mapillary plugin 1.5.20?

[Don-vip]

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

[Don-vip]

Steps to reproduce from #17864:

Here are steps that so far reproduce the hang pretty reliably for me with Mapillary downloads set to manual:

• Download data in some area with Mapillary images.
• Add Mapillary layer (shift+,).
• Download Mapillary images (shift+.).
• Select/open a Mapillary image.
• Open Mapillary filtering and set it to show images, not older than one day (so that the currently displayed image is not show on the map).
• Download Mapillary images again (shift+.).

Note that the last step might require panning/zooming a bit, before the download is initiated.

[richlv]

Yep, got it easy to hang still.

[Don-vip]

OK thanks. @jpietri did you start to look on this one?

[anonymous]

I had a look at it some times ago @Don-vip. I could reproduce it from time to time. But unfortunately, I could not spot the issue, and I won't be able to investigate further on until the end of this year.
The possibly involved code (image download) is on both sides: the Mapillary plugin and some superclasses in JOSM core.

[mueschel]

I have similar issues here.
Mapillary works well, unless I delete a data layer and create a new one:

• open JOSM, download some data, add Mapillary layer - everything works, even for hours, additional downloads and panning are no problem
• delete data layer, download some new data - JOSM freezes after few seconds, before any Mapillary information is shown

Identification: JOSM/1.5 (15492 en) Linux Ubuntu 19.04
Memory Usage: 439 MB / 2984 MB (162 MB allocated, but free)
Java version: 11.0.2+9-LTS, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM

[richlv]

Unfortunately, this still happens with the latest JOSM+plugins version.

[richlv]

Still happens with latest tested JOSM and latest plugins.

[taylor.smock]

I think I fixed this in ​https://github.com/JOSM/Mapillary/commit/e1710fce8a5a5656d646a7a162554b540fa1fb4b , so Mapillary v1.5.21+ (April 07, 2020) should have the fix.

@richlv/@skyper/@mueschel: Can any of you still reproduce this issue?

[mueschel]

In the last weeks I was using v1.5.20 / JOSM 16239 (only today I upgraded to v1.5.22) and had the impression that this bug didn't appear anymore since at least one month. So, the bug seems to be gone at least on my installation, but not related to v1.5.21.

[richlv]

I've developed a habit of not using Mapillary images in JOSM that much, thus cannot say for sure - but haven't had a hang like that recently. Will use it a bit more.
Thank you for all the updates to the plugin :)

[taylor.smock]

@richlv: If you have a specific issue with the Mapillary plugin, a bug report would be appreciated. It might not be something I can work on for awhile, but at least I'll know its a problem.

[richlv]

Sounds great - is Trac here still the preferred location for reporting things?

[taylor.smock]

I have a feed set up for JOSM trac which I go through looking for bugs. I haven't set up the equivalent for GitHub, but I'm not the only developer for the Mapillary plugin. I prefer JOSM trac over Github issues, personally, but other devs may have different perspectives.

I try to look at both, but I may forget about checking Github issues for a week or two.

So, to answer your question, I don't know (for the Mapillary plugin). I just know I check JOSM trac, and occasionally look at Github Issues.

[taylor.smock]

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

[taylor.smock]

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

[taylor.smock]

I'm closing #17971, #18656, and #18704. I'm confident enough that the problem is actually fixed, and none of the ticket reports have indicated that it is still a problem.

See ​e1710fce8a5a5656d646a7a162554b540fa1fb4b for more details.