This is about my attempts to make the “GNOME Maps” app work on a Librem 5 Birch. Comments and suggestions about better/other ways of troubleshooting this kind of things, are most welcome.
After installing GNOME Maps through the “Software” GUI, at first it does not seem to work, just hangs with a blank screen when trying to start it.
Starting it from the terminal shows that it crashed:
purism@pureos:~$ gnome-maps
(org.gnome.Maps:3450): Gjs-WARNING **: 08:14:58.112: Some code called array.toString() on a Uint8Array instance. Previously this would have interpreted the bytes of the array as a string, but that is nonstandard. In the future this will return the bytes as comma-separated digits. For the time being, the old behavior has been preserved, but please fix your code anyway to explicitly call ByteArray.toString(array).
(Note that array.toString() may have been called implicitly.)
0 <TOP LEVEL> ["resource:///org/gnome/Maps/js/osmTypes.js":32]
1 <TOP LEVEL> ["resource:///org/gnome/Maps/js/osmEditDialog.js":35]
2 <TOP LEVEL> ["resource:///org/gnome/Maps/js/osmEdit.js":25]
3 <TOP LEVEL> ["resource:///org/gnome/Maps/js/contextMenu.js":33]
4 <TOP LEVEL> ["resource:///org/gnome/Maps/js/mainWindow.js":33]
5 <TOP LEVEL> ["resource:///org/gnome/Maps/js/application.js":35]
6 <TOP LEVEL> ["resource:///org/gnome/Maps/js/main.js":43]
7 start() ["resource:///org/gnome/gjs/modules/package.js":209]
8 <TOP LEVEL> ["/usr/bin/gnome-maps":2]
Segmentation fault
I think the warning is probably nothing to worry about, seems unrelated to the Segmentation fault crash.
Then I had the idea of trying to run it through the gdb debugger, to see where and why it crashes. However, gdb would not run it because “No executable file specified”. If it’s not an executable file, then what is it?
purism@pureos:~$ which gnome-maps
/usr/bin/gnome-maps
purism@pureos:~$ ls -l /usr/bin/gnome-maps
lrwxrwxrwx 1 root root 34 Dec 11 2018 /usr/bin/gnome-maps -> ../share/gnome-maps/org.gnome.Maps
purism@pureos:~$ cat /usr/bin/gnome-maps
#!/usr/bin/gjs
imports.package.start({ name: "gnome-maps",
version: "3.30.3",
prefix: "/usr",
libdir: "/usr/lib/aarch64-linux-gnu" });
So the /usr/bin/gnome-maps file is a little script that starts something using /usr/bin/gjs which comes from the gjs package, “Mozilla-based javascript bindings for the GNOME platform”. Maybe it would be possible to run the javascript engine through gdb and then start gnome-maps on top of that, but I’m not sure how to do that.
My next idea was to run through valgrind, hoping that could show where the crash happens.
purism@pureos:~$ valgrind gnome-maps
==3557== Memcheck, a memory error detector
==3557== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==3557== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==3557== Command: /usr/bin/gnome-maps
==3557==
==3557== Warning: set address range perms: large range [0x19160b09c000, 0x19164b09c000) (noaccess)
[... skipped several "Invalid read" and "Invalid write" errors in /usr/lib/aarch64-linux-gnu/libmozjs-60.so.0.0.0 ...]
==3557== Process terminating with default action of signal 11 (SIGSEGV)
==3557== Access not within mapped region at address 0x59
==3557== at 0x5E939B4: ??? (in /usr/lib/aarch64-linux-gnu/libmozjs-60.so.0.0.0)
==3557== by 0x6159A8B: ??? (in /usr/lib/aarch64-linux-gnu/libmozjs-60.so.0.0.0)
==3557== by 0x5D5BCD3: ??? (in /usr/lib/aarch64-linux-gnu/libmozjs-60.so.0.0.0)
==3557== by 0x5D644B7: ??? (in /usr/lib/aarch64-linux-gnu/libmozjs-60.so.0.0.0)
==3557== by 0x5D69B47: ??? (in /usr/lib/aarch64-linux-gnu/libmozjs-60.so.0.0.0)
==3557== by 0x5D6B417: ??? (in /usr/lib/aarch64-linux-gnu/libmozjs-60.so.0.0.0)
==3557== by 0x5D6B537: ??? (in /usr/lib/aarch64-linux-gnu/libmozjs-60.so.0.0.0)
==3557== by 0x5FB161B: ??? (in /usr/lib/aarch64-linux-gnu/libmozjs-60.so.0.0.0)
==3557== by 0x5FB1717: ??? (in /usr/lib/aarch64-linux-gnu/libmozjs-60.so.0.0.0)
==3557== by 0x4C5520B: GjsModule::evaluate_import(JSContext*, JS::Handle<JSObject*>, char const*, unsigned long, char const*, int) (in /usr/lib/libgjs.so.0.0.0)
==3557== by 0x4C54D43: gjs_module_import (in /usr/lib/libgjs.so.0.0.0)
==3557== by 0x4C4DCE3: ??? (in /usr/lib/libgjs.so.0.0.0)
==3557== If you believe this happened as a result of a stack
==3557== overflow in your program's main thread (unlikely but
==3557== possible), you can try to increase the size of the
==3557== main thread stack using the --main-stacksize= flag.
==3557== The main thread stack size used in this run was 8388608.
So that was good, it shows that what goes wrong is perhaps not in the gnome-maps code itself, but in the libmozjs-60 library. That’s in the libmozjs-60-0 package, “SpiderMonkey JavaScript library”, https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey – “SpiderMonkey: The Mozilla JavaScript runtime”.
Maybe a bug in libmozjs-60 then?
Next idea: rebuild libmozjs-60 from source, possibly without optimizations and with some debug options.
The source code can be fetched using “apt-get source” provided that some deb-src line(s) are added to the /etc/apt/sources.list file, this seems to work (just added the deb-src line, the rest is the same as it was originally):
purism@pureos:~$ cat /etc/apt/sources.list
deb https://repo.pureos.net/pureos amber main
deb-src https://repo.pureos.net/pureos amber main
deb https://repo.pureos.net/pureos amber-updates main
deb https://repo.pureos.net/pureos amber-security main
deb https://repo.pureos.net/pureos amber-phone main
Now, get the source code:
apt-get source libmozjs-60-0
That works, it downloads the source code and extracts it to a new directory called “mozjs60-60.2.3”. At this point it is possible to go inside that directory and try to rebuild the package frmo source using the command “dpkg-buildpackage -us -uc” – for me, that failed because I ran out of memory. Using fewer threads worked: the command “dpkg-buildpackage -us -uc -j2” worked, took a long time (about 10 hours) but generated new deb files that could be installed.
Building from source like that generated 4 deb files:
libmozjs-60-0-dbgsym_60.2.3-3_arm64.deb
libmozjs-60-0_60.2.3-3_arm64.deb
libmozjs-60-dev-dbgsym_60.2.3-3_arm64.deb
libmozjs-60-dev_60.2.3-3_arm64.deb
which could then be installed using
sudo dpkg --install *.deb
Then, when running gnome-maps again after that, the newly built libmozjs-60 library was used, I was able to verify that by adding some printf statements so I could see that it was really mu modified code that was running when gnome-maps was started. However, it still crashed in the same way as before.
At this point I was thinking that there was a bug in libmozjs-60 and I was aiming at finding out more about it. First I wanted to build without compiler optimizations, both to build faster and to make degugging easier. The libmozjs-60 code is mostly C++ so setting the CXXFLAGS variable might work. Apparently DEB_CFLAGS_SET and DEB_CXXFLAGS_SET can be used to make the dpkg-buildpackage procedure use some specific compiler flags, the following command worked to build with -O0 (no compiler optimization) for both CFLAGS and CXXFLAGS:
DEB_CFLAGS_SET="-g -O0" DEB_CXXFLAGS_SET="-g -O0" dpkg-buildpackage -us -uc -j2
After having rebuilt the deb files in that way, and reinstalled them again, the crash no longer happened. Perhaps the problem was due to a compiler bug then, since turning on compiler optimizations should not make the resulting code crash.
Anyway, in this way I ended up with my own version of the libmozjs-60 package which makes the gnome-maps crash problem disappear. I tried installing the official libmozjs-60 package again ad then the crash comes back, so it seems clear that there some kind of problem with the libmozjs-60-0/amber package, version 60.2.3-3 (although maybe not a bug in the libmozjs-60 suorce code but rather a problem with the cmopiler used to build it).
It would be interesting to try building with a newer compiler to see if that helps (this was using gcc 8.3.0), I haven’t tried that yet.
When it started without crashing, it first said “Maps is offline” and would not show any map. The following command helped solve that:
sudo nmcli networking connectivity check
Maybe the problem there was that root privileges are needed for that command but gnome-maps is not running as root. Luckily it seems enough to have run that nmcli command once, after that it seems gnome-maps is able to use the network each time it starts.
So then it was possible to start GNOME Maps and it did show a map.
I made this little video showing it running:
Some issues:
- it seems to have the wrong idea about the screen size, as seen in the video it does not zoom in towards the center of the screen, looks like it thinks the screen is wider than it actually is.
- touch input works only for buttons, I cannot move the map by dragging it, seems like the map part of the screen completely ignores touch input.
Other than that, I’m quite impressed at how well it works “out of the box”. Zooming with the buttons works, and moving the map can be done via the arrow keys on the onscreen keyboard. It draws the map fairly quickly. Searching for a place name works, although part of the text ends up outside the screen.
That’s it for now. If anyone has ideas about how to make it work better, please let me know.
Thankfully byzantium on L5 is slowly getting usable and it already contains much fresher set of GNOME apps. Flatpak isn’t always the best answer since the runtimes there are missing some patches that make things mobile friendly, but in some cases it works well enough indeed