Bug#1065678: josm: JOSM hangs when downloading Bing imagery, but only the first time in a session

Fri Mar 8 20:30:25 GMT 2024

Package: josm
Version: 0.0.svn18969+dfsg-1
Severity: normal
X-Debbugs-Cc: a.t.chadwick at gmail.com

Dear Maintainer,

When JOSM is instructed to download Bing background satellite and aerial 
imagery, it hangs the first time JOSM is launched on a day of map editing. 
It seems to be a key caching issue. If JOSM is then killed, and 
subsequently launched again, it downloads the Bing imagery just fine.

If enough time then elapses without launching JOSM, the situation repeats. 
For me this is usually about a day, but the timeframe is probably a lot 
shorter.

I would expect Bing background imagery to be downloaded fine every time, 
without causing JOSM to hang.

## Minimal Steps to Reproduce

The hang will happen in all ordinary usage when Bing imagry is used, but in 
order to rule out config files and settings, you can run JOSM as

   $ JAVA_OPTS="-Djosm.home=/tmp/josmhome.$$" josm --skip-plugins --debug

This prevents it from loading your personal config file or any downloaded 
plugins. As soon as the main interface loads, add a Bing layer using

   Imagery → Bing aerial imagery

If this is the *first* time the josm.home location is being used (i.e. it 
didn’t exist before), JOSM will then hang with the final debug messages
shown immediately below. JOSM then hangs and has to be killed with ^C or 
using xkill.

-----------------------8<----------------------
[...]
2024-03-08 20:12:56.115 FINE: Unsupported savable layer type: TMSLayer
2024-03-08 20:12:56.120 FINE: Contacting Server...
2024-03-08 20:12:56.120 FINE: REQUEST HEADERS: {Accept=*/*, Accept-Encoding=gzip, deflate}
2024-03-08 20:12:56.223 INFO: GET https://dev.virtualearth.net/REST/v1/Imagery/Metadata/AerialOSM?include=ImageryProviders&output=xml&key=...stripped... -> HTTP/1.1 200 (102 ms)
2024-03-08 20:12:56.223 FINE: RESPONSE HEADERS: {Transfer-Encoding=[chunked], null=[HTTP/1.1 200 OK], X-Cache=[CONFIG_NOCACHE], x-azure-ref=[20240308T201256Z-39saph36ah08xe5gfvn6y1z8pw000000083g0000000001pm], X-BM-TraceID=[cbf82a8a7dda1cbe233823c5d9cd1a91], Alt-Svc=[h3=":443"; ma=86400], Access-Control-Allow-Origin=[*], Access-Control-Allow-Methods=[POST, GET, OPTIONS], X-BM-FE-Elapsed=[5], Connection=[keep-alive], Access-Control-Allow-Headers=[Content-Type,X-FD-Features,X-FD-FLIGHT,PreferAnonymous], Date=[Fri, 08 Mar 2024 20:12:56 GMT], Cache-Control=[no-cache], X-AspNet-Version=[4.0.30319], X-BM-Srv=[mapsplatform-frontend-55b6b7bd84-p2lfw, DU00003064], Content-Encoding=[gzip], Vary=[Accept-Encoding], X-MS-BM-WS-INFO=[0], X-Powered-By=[ASP.NET], Content-Type=[application/xml; charset=utf-8]}
2024-03-08 20:12:56.223 FINE: Downloading data...
2024-03-08 20:12:56.224 INFO: Successfully loaded Bing attribution data.
[hangs, ^C]
----------------------->8----------------------

If it’s the *second* time around (within some unknown number of minutes), 
JOSM does not hang, and goes on to print messages like

-----------------------8<----------------------
2024-03-08 20:17:01.005 FINE: Unsupported savable layer type: TMSLayer
2024-03-08 20:17:01.033 FINE: Reading Bing logo from https://dev.virtualearth.net/Branding/logo_powered_by.png
2024-03-08 20:17:01.038 FINE: Contacting Server...
2024-03-08 20:17:01.039 FINE: REQUEST HEADERS: {Accept=*/*, Accept-Encoding=gzip, deflate}
2024-03-08 20:17:01.420 INFO: GET https://dev.virtualearth.net/Branding/logo_powered_by.png -> HTTP/1.1 200 (381 ms; 1.17 kB)
2024-03-08 20:17:01.420 FINE: RESPONSE HEADERS: {Accept-Ranges=[bytes], null=[HTTP/1.1 200 OK], X-Cache=[CONFIG_NOCACHE], Alt-Svc=[h3=":443"; ma=86400], Cache-Control=[max-age=86400], ETag=["1da6b47d7e7e12e"], Last-Modified=[Thu, 29 Feb 2024 19:45:27 GMT], X-Azure-Ref=[0PXLrZQAAAABRV4dQ4FinSYsXKjq3EwHuTE9OMjFFREdFMTgxMgBmMTI3MDYwYi1mNDk4LTRlMjAtYjVkZi1hZWIyMzczZWM5NWU=], Content-Length=[1198], Date=[Fri, 08 Mar 2024 20:17:00 GMT], Content-Type=[image/png]}
2024-03-08 20:17:01.421 FINE: Downloading data...
2024-03-08 20:17:01.480 INFO: AbstractTileSourceLayer: estimated visible tiles: 54, estimated cache size: 466
2024-03-08 20:17:01.484 FINE: zoomChanged(): 2
2024-03-08 20:17:01.580 INFO: AbstractTileSourceLayer: estimated visible tiles: 54, estimated cache size: 466
2024-03-08 20:17:01.629 INFO: AbstractTileSourceLayer: estimated visible tiles: 54, estimated cache size: 466
2024-03-08 20:17:01.631 INFO: Allocate for tile source layer: 116 MB of memory. Available: 3 914 MB.
2024-03-08 20:17:01.644 FINE: zoomChanged(): 14
2024-03-08 20:17:01.645 FINE: JCS - Submitting job for execution for url: https://ecn.t2.tiles.virtualearth.net/tiles/a30000000000000.jpeg?g=14355&pr=odbl
2024-03-08 20:17:01.646 FINE: JCS - Submitting job for execution for url: https://ecn.t1.tiles.virtualearth.net/tiles/a21111111111111.jpeg?g=14355&pr=odbl
2024-03-08 20:17:01.646 FINE: JCS - starting fetch of url: https://ecn.t2.tiles.virtualearth.net/tiles/a30000000000000.jpeg?g=14355&pr=odbl 
2024-03-08 20:17:01.646 FINE: JCS - starting fetch of url: https://ecn.t1.tiles.virtualearth.net/tiles/a21111111111111.jpeg?g=14355&pr=odbl 
2024-03-08 20:17:01.647 FINE: JCS - Submitting job for execution for url: https://ecn.t1.tiles.virtualearth.net/tiles/a12222222222222.jpeg?g=14355&pr=odbl
2024-03-08 20:17:01.647 FINE: JCS - starting fetch of url: https://ecn.t1.tiles.virtualearth.net/tiles/a12222222222222.jpeg?g=14355&pr=odbl 
2024-03-08 20:17:01.647 FINE: JCS - starting HttpClient GET request for URL: https://ecn.t1.tiles.virtualearth.net/tiles/a21111111111111.jpeg?g=14355&pr=odbl
2024-03-08 20:17:01.647 FINE: JCS - starting HttpClient GET request for URL: https://ecn.t2.tiles.virtualearth.net/tiles/a30000000000000.jpeg?g=14355&pr=odbl
2024-03-08 20:17:01.647 FINE: JCS - Submitting job for execution for url: https://ecn.t3.tiles.virtualearth.net/tiles/a30000000000002.jpeg?g=14355&pr=odbl
2024-03-08 20:17:01.648 FINE: Contacting Server...
----------------------->8----------------------

And so on. The program is now fully usable.

I would guess this is a cache directory liveness issue. That’s because the 
misbehaviour can also be provoked by deleting JOSM’s cache (which is 
normally ~/.cache/JOSM) before launching JOSM with your normal prefs, 
plugins, and presets. JOSM will then hang regardless of when it’s launched: 
the hang happens when JOSM is doing its Bing cache initialization or a full 
refresh (perhaps some magic numbers for the service?)

The workaround is to launch JOSM and try and download Bing imagery, let it 
hang, then kill it and start it again. A bit annoying to have to do before 
each editing session, but it works.

   thanks for maintaining,
   Andrew

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (5, 'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages josm depends on:
ii  default-jre [java9-runtime]     2:1.17-75
ii  fonts-noto                      20201225-2
ii  jmapviewer                      2.19+dfsg-1
ii  libcommons-compress-java        1.25.0-1
ii  libgettext-commons-java         0.9.6-6
ii  openjdk-17-jre [java9-runtime]  17.0.10+7-1
ii  openjfx                         11.0.11+1-3.1
ii  proj-data                       9.3.1-1

Versions of packages josm recommends:
ii  josm-l10n  0.0.svn18969+dfsg-1

josm suggests no packages.

-- Configuration Files:
/etc/default/josm changed:

-- no debconf information