Sporadic crashes right after download - Failed to load module "topmenu-gtk-module" - BadWindow (invalid Window parameter)

[stanton]

What steps will reproduce the problem?

1. Start JOSM
2. Download from Overpass API with the following query (all milestones in Poland; this takes some time)

[out:xml][timeout:90];
area["admin_level"=2]["name:en"="Poland"]->.searchArea;
(
  node["highway"="milestone"](area.searchArea);
);
(._;>;);
out meta;

What is the expected result?

Data is downloaded and rendered; then I can start editing

What happens instead?

Sometimes this works as expected. Other times JOSM starts rendering (I still see the map view with the milestones very briefly), then it crashes.

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

Right now this behavior is fairly reproducible, i.e. the above steps crashed JOSM with every single of multiple tries. I did eventually manage to do a full download (directly from OSM) of a small area, then download from Overpass into the existing data layer: this time JOSM did not crash.

Running JOSM from the command line (java -Djosm.restart=true -Djava.net.useSystemProxies=true --add-modules java.scripting,java.sql -jar /usr/share/josm/josm.jar) and reproducing the crash tells me this is not an unhandled Java exception but a Gtk error:

Gtk-Message: 17:05:53.974: Failed to load module "topmenu-gtk-module"
The program 'java' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 20887 error_code 3 request_code 20 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

JOSM debug info (from a fresh JOSM instance, started from the desktio GUI):

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2021-07-12 02:41:41 +0200 (Mon, 12 Jul 2021)
Revision:18004
Build-Date:2021-07-12 00:42:49
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (18004 en) Linux Ubuntu 20.04.2 LTS
Memory Usage: 754 MB / 3978 MB (294 MB allocated, but free)
Java version: 11.0.11+9-Ubuntu-0ubuntu2.20.04, Ubuntu, OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Screen: :0.0 1600×900 (scaling 1.00×1.00) :0.1 1600×900 (scaling 1.00×1.00)
Maximum Screen Size: 1600×900
Best cursor sizes: 16×16→16×16, 32×32→32×32
Environment variable LANG: en_US.UTF-8
System property file.encoding: UTF-8
System property sun.jnu.encoding: UTF-8
Locale info: en_US
Numbers with default locale: 1234567890 -> 1234567890
Desktop environment: MATE
Java package: openjdk-11-jre:amd64-11.0.11+9-0ubuntu2~20.04
Java ATK Wrapper package: libatk-wrapper-java:all-0.37.1-1
libcommons-compress-java: libcommons-compress-java:all-1.19-1
libcommons-logging-java: libcommons-logging-java:all-1.2-2
fonts-noto: fonts-noto:all-20200323-1build1~ubuntu20.04.1
VM arguments: [--add-modules=java.scripting,java.sql, -Djosm.restart=true, -Djava.net.useSystemProxies=true]

Plugins:
+ DirectUpload (35640)
+ InfoMode (35543)
+ KartaView (374)
+ Mapillary (2.0.0-alpha.28-dirty)
+ MicrosoftStreetside (35779)
+ PicLayer (1.0.1)
+ SimplifyArea (35640)
+ apache-commons (35524)
+ apache-http (35589)
+ cadastre-fr (35797)
+ ejml (35458)
+ geotools (35458)
+ javafx-unixoid (35655)
+ jna (35662)
+ jts (35458)
+ measurement (35640)
+ merge-overlap (35640)
+ photo_geotagging (35783)
+ print (35640)
+ reverter (35732)
+ todo (30306)
+ turnrestrictions (35640)
+ undelete (35640)
+ utilsplugin2 (35792)

Last errors/warnings:
- 00004.186 E: java.lang.UnsatisfiedLinkError: <josm.pref>/plugins/javafx/libavplugin-54.so: libgstreamer-lite.so: cannot open shared object file: No such file or directory
- 00004.191 E: java.lang.UnsatisfiedLinkError: <josm.pref>/plugins/javafx/libavplugin-ffmpeg-57.so: libgstreamer-lite.so: cannot open shared object file: No such file or directory
- 00004.195 E: java.lang.UnsatisfiedLinkError: <josm.pref>/plugins/javafx/libavplugin-ffmpeg-56.so: libgstreamer-lite.so: cannot open shared object file: No such file or directory
- 00004.199 E: java.lang.UnsatisfiedLinkError: <josm.pref>/plugins/javafx/libavplugin-ffmpeg-58.so: libgstreamer-lite.so: cannot open shared object file: No such file or directory
- 00004.264 E: java.lang.UnsatisfiedLinkError: <josm.pref>/plugins/javafx/libavplugin-56.so: libgstreamer-lite.so: cannot open shared object file: No such file or directory
- 00004.267 E: java.lang.UnsatisfiedLinkError: <josm.pref>/plugins/javafx/libavplugin-57.so: libgstreamer-lite.so: cannot open shared object file: No such file or directory

[Don-vip]

I have no idea how to debug GTK issues... You might have more luck in reporting this issue to Debian Java team. It is probably something we can't fix from JOSM.

[stanton]

Just found something else: downloading a small area, then downloading from Overpass into a new layer (and then discarding the other) is also a workaround for this bug.

As for redirecting the issue to the Debian Java team: even if this should ultimately turn out to be caused by a JRE bug, I fear one of the two will happen: either the Debian Java team will request information which I cannot supply (as I do not know the inner workings of JOSM) and close the ticket if I cannot, or might outright send me back to the JOSM team. I have seen plenty of bugs related to the interaction between two systems where each maintainer insisted that the other had to fix it. They might just tell me you’re not using their APIs correctly.

At JOSM, you may not be able to fix the bug altogether. But you probably know better than anyone else (including the Debian Java team and myself) what calls to the Java APIs you make when rendering a new layer downloaded from Overpass, and which of them are related to the GUI, and would be able to narrow this down. You might then be able to single out which API call triggers the bug and report it to the Debian Java team, or work around it.

So far, we can narrow the offending call down in the following ways:

• it occurs when downloading from the start screen, i.e. the main map view and side panels still need to be created, not when these controls are already in place
• it occurs relatively late in the process, after the map view is shown on the screen and the side panels also seem to be (mostly) there

First step: can you reproduce the crash at all? If so, you might be able to skip some of the things that happen after the map view is created and see if JOSM still crashes, or insert a few breakpoints and see which is the last one that is reached before JOSM crashes. Such things would probably be valuable information to supply to the Java team, but that takes someone familiar with the code.

[skyper]

See ​https://ubuntu-mate.community/t/gtk-message-failed-to-load-module-topmenu-gtk-module/4964

[Don-vip]

Well I don't have a Linux dev environment right now, so I can't reproduce. As for identifying the Java API that triggers the error... It's like searching a needle in a haystack: JOSM being a Swing application, we call (directly or not) a lot of Java APIs that could cause the problem.

Would it be possible for you to debug JOSM/GTK with the command line arguments advised in the GTK error message, to see if you can get more information?

[stanton]

Sure, I will see what I can find out (though I am not an expert on GDB and cannot guarantee the stack trace will produce anything meaningful – if the java binary does not include debug symbols, we might just see a bunch of hex addresses for unnamed functions).

Right now, I cannot reproduce this issue any more but I have no idea what I changed to influence this behavior – so bear with me, we’ll have to wait for the issue to strike again. What I will also try to do next time is disable plugins one by one (or by means of bisection), to determine if it is related to a plugin.

[stanton]

Amendment: java --sync -Djosm.restart=true -Djava.net.useSystemProxies=true --add-modules java.scripting,java.sql -jar /usr/share/josm/josm.jar gives me:

Unrecognized option: --sync
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

Any ideas how to supply this command line option?

[stanton]

Another crash (upgraded to JOSM 18118 in the meantime). After the crash I disabled the StreetView, KartaView and Mapillary plugins and retried; this time it worked. I still have to single out the culprit plugin, if that is what caused the crash.

As for debugging, I tried running Java-cum-JOSM inside gdb, which segfaulted before I even got to see the main window. In any case, gdb tells me the java binary has no debug symbols, which means stack traces would not be very useful.

[stanton]

After reactivating Mapillary and then KartaView, it still works (though I had to wait a while as my test case can quickly exhaust my quota on Overpass). Of course, given the sporadic nature of the bug, it doesn’t necessarily mean StreetView is at fault.