Crashes when running Fedora package

[subpop]

Environment

• FreeOrion Version: 0.4.7.1
• Operating System: Linux (Fedora 28)
• Graphic card used: Intel HD 520
• Fetched as
  • Compiled from source

Description

I am maintaining the FreeOrion in Fedora. I recently started receiving crash reports of a crash occurring immediately when running /usr/bin/freeorion. The message when crashing is:

/usr/include/c++/8/bits/stl_vector.h:950: std::vector<_Tp, _Alloc>::const_reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) const [with _Tp = float; _Alloc = std::allocator<float>; std::vector<_Tp, _Alloc>::const_reference = const float&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n < this->size(), true)' failed.

From the stack trace reported on retrace.fedoraproject.org, it's passing through some font render related function calls. I checked my installed versions of DejaVu and Roboto fonts. I also ran /usr/bin/freeorion --resource-dir ~/git/freeorion/data/default and it still crashes, so it's not a problem with the system version of the fonts. Is there something else I should check? Freetype versions or Boost versions?

Expected Result

I expect the game to simply launch. :)

Steps to reproduce

• Install freeorion from the Fedora repository: dnf install freeorion
• Run freeorion

Links

• The spec file and related sources can be found on src.fedoraproject.org: https://src.fedoraproject.org/rpms/freeorion
• The stack trace for the crash has been captured by a crash tracer: https://retrace.fedoraproject.org/faf/reports/2087972/
• The bug report contains additional data about the system that reported the crash: https://bugzilla.redhat.com/show_bug.cgi?id=1575292

[dbenage-cx]

I can reproduce from repo installed version (bt), but not from checking out v0.4.7.1 + cherry-pick c9b5b13.

Comparing build instructions (If unresolved, I'll try to go through these another day):
fedoraproject:

/usr/bin/c++  -DBOOST_ALL_DYN_LINK -DBOOST_ALL_NO_LINK -DBOOST_LOG_DYN_LINK -DENABLE_BINRELOC -DFREEORION_LINUX -DGiGi_EXPORTS -I/builddir/build/BUILD/src-tarball/GG -isystem /usr/include/freetype2  -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -mcet -fcf-protection -DNDEBUG -fPIC   -Wall -std=c++11 -o CMakeFiles/GiGi.dir/src/GLClientAndServerBuffer.cpp.o -c /builddir/build/BUILD/src-tarball/GG/src/GLClientAndServerBuffer.cpp

local cmake:

/usr/lib64/ccache/c++  -DBOOST_ALL_DYN_LINK -DBOOST_ALL_NO_LINK -DBOOST_LOG_DYN_LINK -DENABLE_BINRELOC -DFREEORION_LINUX -DGiGi_EXPORTS -I/opt/projects/freeorion/GG -I/opt/projects/freeorion/build-4.7.1/GG -isystem /usr/include/freetype2  -O2 -DNDEBUG -fPIC   -Wall -std=c++11 -o CMakeFiles/GiGi.dir/src/GLClientAndServerBuffer.cpp.o -c /opt/projects/freeorion/GG/src/GLClientAndServerBuffer.cpp

I do not suspect the following is an issue here, but I do not have such warnings.
From the last build log for freeorion-0.4.7.1-8.fc28.x86_64, there are multiple warnings for:

CMake Warning at /usr/share/cmake/Modules/FindBoost.cmake:801 (message):
  New Boost version may have incorrect or missing dependencies and imported
  targets
Call Stack (most recent call first):
  /usr/share/cmake/Modules/FindBoost.cmake:907 (_Boost_COMPONENT_DEPENDENCIES)
  /usr/share/cmake/Modules/FindBoost.cmake:1542 (_Boost_MISSING_DEPENDENCIES)
  CMakeLists.txt:153 (find_package)

[Dilvish-fo]

I also feel constrained to point out that 0.4.7.1 is nearly a year old at this point, and itself was merely a bugfix release for a yet older version. There have been quite a few changes to the code since then, including the commit dbenage-cx mentioned and at least one other font related safety check which seems potentially related

At this point we are right in the process of trying to wrap up 0.4.8. So please try building the 0.4.8 branch. The commit that dbenage-cx already mentioned is already in that branch. If you nevertheless still have the same issue with it, perhaps there is some chance that the issue could get sorted out quickly enough for the fix to make it into 0.4.8.

[subpop]

So, that's an interesting data point then. We already pulled in c9b5b13 and apply it during %prep. Is this a case of some compiler optimizations that don't happen during debug builds?

[subpop]

I did try 0.4.8-rc1 actually; it still crashed. You can see the scratch build here.

[subpop]

I backported 4538457 into another standalone patch and am running a scratch build including it here. When that build completes, it could be worth trying that RPM.

Edit: Seems the build still fails to run even with this patched.

[subpop]

Fedora does seem to inject some compiler flags into $CFLAGS for builds. For example, on my local system:

rpmspec -E '%build_cxxflags' freeorion.spec
-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection

[dbenage-cx]

Adding GLIBCXX_ASSERTIONS looks to be enough to reproduce

[dbenage-cx]

Not certain of correct behavior here, looks like some change starting with GCC 7? https://godbolt.org/g/Sx8Tx8

[subpop]

The documentation around _GLIBCXX_ASSERTIONS makes it sound like a Good Thing:tm:. I can certainly just build the package without that flag, but it's been enabled by Fedora for a reason. Is the better fix to try and figure out why that assertion is getting tripped?

Undefined by default. When defined, enables extra error checking in the form of precondition assertions, such as bounds checking in strings and null pointer checks when dereferencing smart pointers.

[dbenage-cx]

I initially started down that path. dbenage-cx@06aaf63 allows the game to launch, but aborts on clicking Single Player.

The same message is displayed from stl_vector.h:950(via ListBox::Row::SetColumnStretches).
Resolving that leads to another instance of same message via GLClientAndServerBufferBase::createServerBuffer.
Started to look like a never ending chase, but I'll continue to plug away this week.

This issue is relevant for current master as well.

[subpop]

Oh interesting. So that assertion is tripping all over the place.

[Dilvish-fo]

Looks like a bunch of great bugs to get squashed. Go go dbenage-cx!