Mapper: Segmentation fault in Fedora 33

[enpontus]

Steps to reproduce

1. run Mapper program
   2.
   3.

Actual behaviour

Segmentation fault

Expected behaviour

joy

Configuration

Mapper Version:openorienteering-mapper-0.9.4-31.2.x86_64
Operating System:Fedora 33 (Linux)
oom-coredump.txt

I am not very skilled at debugging but can try to assist with some instructions!

[enpontus]

oom-backtrace.txt
adding a first try for a backtrace

[dg0yt]

There was a previous issue with Mapper on Fedora 32, https://github.com/OpenOrienteering/mapper/issues/1678.
Is this a Wayland display, possibly using Xwayland?
What about other Qt programs on wayland? E.g. assistant or linguist.
To start Mapper in "Wayland mode" you need to add -platform wayland on the Mapper command line.

[dg0yt]

FTR: https://fedoraproject.org/wiki/How_to_debug_Wayland_problems#Identifying_Wayland_problems

If this issue can be narrowed down to Wayland/Xwayland, we might want to look for the WAYLAND_DISPLAY environment variable during Mapper startup.

[enpontus]

when running Mapper -platform wayland i get this response:
[pontus@rattika ~]$ Mapper -platform wayland
Failed to create wl_display (No such file or directory)
qt.qpa.plugin: Could not load the Qt platform plugin "wayland" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.

Aborted (core dumped)

oom-backtracce2.txt

[enpontus]

notably other Qt applications seem to work (qcad, qgis)

[dg0yt]

qt.qpa.plugin: Could not load the Qt platform plugin "wayland" in "" even though it was found.

Maybe you are really not in a Wayland session. See above link for how to check it.

notably other Qt applications seem to work (qcad, qgis)

Thanks for verifying. So there seems to be some usage pattern in Mapper bootstrapping which triggers an error in Qt
5.15.1 on Fedora.

[enpontus]

you are right - logged into wayland again and restarted....
...attaching new backtrace
oom-backtrace3.txt

[enpontus]

installed a few more debuginfo packages if that helps

oom-backtrace3d.txt

[dg0yt]

Okay, so we have crashes with the wayland platform and with the xcb platform on fedora.

In both cases, the call stack starts at the QtSingleApplication constructor, and the crash is in Qt, when emitting QScreen::screenAdded from QWindowSystemInterface::handleScreenAdded.

• This is the first thing which is called from main.
• Maybe qcad, qgis do not use QtSingleApplication.

So all I know is it is Qt + Fedora + QtSingeApplication.

[enpontus]

a search of the keywords mentioned above in the fedora(redhat) bugzilla yields nothing though - should i try to raise the issue in fedora-land against Qt ?

[dg0yt]

should i try to raise the issue in fedora-land against Qt ?

Not for Mapper. You would need to create minimal reproducible example. E.g. a main which only uses QtSingleApplication and shows the same error. Creating the examples sometimes means finding the actual cause.

I tried to look at the Qt patches in Fedora, but I didn't want to download a full Qt SRPM.

[dg0yt]

I tried to look at the Qt patches in Fedora, but I didn't want to download a full Qt SRPM.

Didn't provide any insight: https://src.fedoraproject.org/rpms/qt5-qtbase/tree/f33

[lpechacek]

I would say this is a miscompilation, i.e. an OBS problem. I've installed F33 and compiled Mapper both in Debug and Release mode. It ran fine.

FTR, Fedora itself has broken Doxygen, so Mapper source has to be tweaked for a successful compilation. I've reported the Doxygen bug as https://bugzilla.redhat.com/show_bug.cgi?id=1893871.

[dg0yt]

Do the master and unstable packages have miscompilation issues, too? One thing in Fedora's patches to Qt is replacing -O3 with -O2.

[dg0yt]

Apart from -O2, might we use another compiler?

[dg0yt]

I've installed F33 and compiled Mapper both in Debug and Release mode. It ran fine.

This means you didn't use the spec file which pulls in default build flags from Fedora?

[lpechacek]

Do the master and unstable packages have miscompilation issues, too?

Both segfault too.

This means you didn't use the spec file which pulls in default build flags from Fedora?

Correct. rpmbuild fails due to missing generic-release (I'm testing on the workstation edition which has fedora-release-workstation) and then it hits the broken Doxygen. Give me some time to hack the build a bit.

[dg0yt]

Correct. rpmbuild fails due to missing generic-release

I think you should get a valid spec from the actual SRPM generated by OBS for Fedora 33.

[lpechacek]

Packaging troubles aside, we've hit the bullseye! The RPM build on Fedora fails in the check phase. The first failing test is file_format_t, crashing with segfault during initialization. The neighboring Mapper executable segfaults as well. So the culprit seems to be in the build flags.

[dg0yt]

Now I remember that I disabled tests at least for Rawhide. I was unable to see why they fail, and thought it was limited to the build environment.

[lpechacek]

So, disabling LTO (%define _lto_cflags %{nil} at the top of the .spec file) helps to get working Fedora 33 executables.

[lpechacek]

Build with Clang fails quite early in CoVe. Clang does not like a narrowing conversion.

Hence my proposal for the fix here would be:
```

Index: openorienteering-mapper.spec

--- openorienteering-mapper.spec (revision 67)
+++ openorienteering-mapper.spec (revision 6)
@@ -13,6 +13,11 @@
# Unless using OBS/osc for building, the resulting spec file in the SRPMS
# provides the best starting point for individual RPM builds.

+# GCC 10 and LTO makes Mapper segfault in Fedora
+%if 0%{?fedora_version} >= 33

• %define _lto_cflags %{nil}
  +%endif
  +
  #%%global branch master
  %global nativename openorienteering-mapper%{?branch:-%{branch}}
  ```

Test packages are available from https://download.opensuse.org/repositories/home:/LPechacek:/fedora33-oomapper/Fedora_33/x86_64/

[dg0yt]

The proposed fix does fix the tests for Rawhide in my OBS staging area. Pushing it forward to home:dg0yt. Thanks!

[enpontus]

THe updated package start and i can open a map again!

thanks for solving this issue!

[dg0yt]

@enpontus Thanks for the detailed report and investigation.

[lpechacek]

Hence my proposal for the fix here

For the record, the workaround can be removed now. Fedora implemented a change in Qt that eliminates the trouble closer to the source (https://bugzilla.redhat.com/show_bug.cgi?id=1873713 and
https://src.fedoraproject.org/rpms/qt5-qtbase/c/d4ab2137a55708d645fcff5ddf92630b8a5de947). I've built Mapper for Fedora 33 with the default compilation flags (i.e. also with LTO) and all went fine.

[dg0yt]

Thanks. I'm just working on Fedora packages anyway. I will give it a try.

[dg0yt]

the workaround can be removed now.

Confirmed: Tests running happily.