stellarium-0.18.0_1 dies with `free() invalid pointer` about void-packages HOT 17 CLOSED

Despite the template saying

only_for_archs="i686 i686-musl x86_64 x86_64-musl"

I was able to successfully (cross-)compile stellarium 0.18.1 for armv7l-musl. Only CMakeLists.txt had to be tweaked a little:

--- CMakeLists.txt.orig	2018-07-01 08:04:19.000000000 +0200
+++ CMakeLists.txt	2018-07-17 08:52:24.193931980 +0200
@@ -418,24 +418,6 @@
      ADD_DEFINITIONS(-DUSE_OLD_QGLWIDGET)
 ENDIF()
 
-# Since Qt 5.4, linking to OpenGL is basically not required anymore,
-# because the QtGui module re-implements the GL functions, and perhaps even
-# dispatches the calls to a dynamically selected GL library.
-#
-# The only exception where this does not work with CMake is for
-# ES2-only/ANGLE-only builds, which are seemingly not included in
-# official Qt downloads, but may be required as a custom build
-# for some embedded systems. Interestingly, this works with qmake,
-# but CMake needs an explicit link definition.
-# See also this bug: https://bugreports.qt.io/browse/QTBUG-29132
-
-# Check if we have a GLES-only build
-# On dynamic builds, this property is also "GL"
-IF(${Qt5Gui_OPENGL_IMPLEMENTATION} MATCHES "GLES")
-     MESSAGE(STATUS "Building an OpenGL ES build (${Qt5Gui_OPENGL_IMPLEMENTATION})")
-     SET(STEL_GLES_LIBS Qt5::Gui_EGL Qt5::Gui_GLESv2)
-ENDIF()
-
 
 # Tell CMake to run moc when necessary:
 SET(CMAKE_AUTOMOC ON)

No idea where to find Qt5::Gui_EGL/GLESv2, but by not linking to them everything is just fine.

But now to the point I’m trying to make: When I run it on my RPi there are no problems with invalid pointers, no crashes, etc. It just works!

So could this problem be compiler related? I think the main difference between the native and cross compilers is that the former still use --with-default-libstdcxx-abi=gcc4-compatible" and the latter don’t. Maybe this is just by accident, however, I thought it might be worth mentioning. ;)

from void-packages.

Oh, looks like it's about time to drop gcc4 compatibility then.
Good to know the true source of all the problems.
I'm going to try locally and push an update for gcc then.

from void-packages.

The problem seems not to be related to the mesa-ati-dri shader implementation because stellarium also crashes in a qemu VM using the swrast_dri.so xorg driver.

from void-packages.

I think this might be the same problem as https://github.com/voidlinux/void-packages/issues/13161 in the old repo.
A possible cause was pointed out in this post.

from void-packages.

Thank you for pointing me in that direction.
I'm looking at that void-qt5-anticrash.c and thinking about how what it does can perhaps be applied before packaging apps like stellarium.

Looking around I found a detailed description of the problem in the qtwebengine source lines 159ff. I wonder why this bug then seems not to be handled in QtOpenGL.

from void-packages.

This is an issue with our Qt5 libraries, so patching apps with void-qt5-anticrash during packaging is not a solution IMO. Even if we could be sure that removing the versioning always has the desired effect, programs built outside of xbps-src could still crash.

It looks like at least the libQt5Location and libQt5Positioning SOs export the symbol. They shouldn't. It has to be globally unique, hence its STB_GNU_UNIQUE binding. I'm not sure what happens if an application that links against both uses std::string, because then there will be two Qt5 symbol versions on top of the GLIBCXX_3.4 one.

IMHO we should:

• Find out why those rogue _S_empty_rep_storage exports exist in the first place
• Fix the relevant qt5-* package(s), e.g. qt5-location
• Rebuild dependent packages

from void-packages.

I agree @mvf - I just don't know yet why we face this problem at all. It seems Void is the only distro with this kind of problem and as such it's maybe my overly complicated(?) srcpkgs/qt5/template causing it.

I think that perhaps linking with -Wl,-F,libstdc++ could solve the problem, i.e. make the linker filter symbols found in libstdc++ from the object files. But I may have misunderstood how -F works with ld.bfd and/or ld.gold.

from void-packages.

I also think it is related to Void's specific build of qt, but I'm not sure. This would be a good thing to check/look for when it's time to update to qt 5.11.x.

In the mean time, try this as quick hack.

~/.stellarium/config.ini:

[plugins_load_at_startup]
...
Satellites                             = false
...

from void-packages.

• xuname:
  Void 4.17.4_1 x86_64 GenuineIntel uptodate rrFFFFFFFFFFFFF

Just to see, this morning I compiled the latest release v0.18.1, but doesn't work:

*** Error in `stellarium': free(): invalid pointer: 0x00005613ce991300 ***
Abandon

@travankor I confirm your "hack" worked for me, too. 👍

from void-packages.

And BTW: SuperCollider is working on my rpi without invalid pointer errors in sclang, too.

from void-packages.

I'm going to try to build qt5-5.11.1 on another box and see if stellarium will work out of the box with this version.

Another test that may be worth trying was to remove -fno-delete-null-pointer-checks from the global CXXFLAGS in the qt5 template. IIRC it was required for gcc-6.x as a workaround for some problem (don't recall which, though) and judging by its name it may have an influence on how the std:string destructor is handled.

from void-packages.

Oops! qt5-5.11.1 cannot be built with libressl. It requires openssl 1.1.x which libressl does not (yet fully?) support.
So I'm going to test removal of -fno-delete-null-pointer-checks here.

from void-packages.

Awesome, @newbluemoon, looks like you found it! Indeed, at least on x86_64, removing --with-default-libstdcxx-abi=gcc4-compatible from the gcc build makes the nasty symbol disappear from the qt5-location SOs! I also checked all packaged binaries except the aarch64es, and only natively built binaries were broken. This includes x86_64-musl, but that doesn't crash, presumably because there the symbol is STB_WEAK instead of STB_GNU_UNIQUE.

from void-packages.

@pullmoll Is there a plan how we rebuild everything without loading both old and new ABI in the same address space?

from void-packages.

My hope is that only few packages will actually exhibit this difference between the CXX11 ABI being enabled or not. Now libGL is the first candidate to try to get to cleanly compile without setting -D_GLIBCXX_USE_CXX11_ABI=0.

I'll try to determine locally which of the libGL dependencies needs to be rebuilt with gcc-7.4.0_4 to avoid the need to disable the CXX11 ABI for it to link.

Other than that I have no plan yet, no, as I don't know where else it may be required to select either ABI. The goal definitely is to get rid of the gcc4 compatibility (i.e. CXX11 ABI disabling) in all packages where it is causing problems.

My box is busy around the clock building packages and I'm observing the results. I think we should use #983 to keep track of the issues and fix them. We have some users who are also able to test and fix packages and this will help to settle the issue methinks.

from void-packages.

-fno-delete-null-pointer-checks ... IIRC it was required for gcc-6.x as a workaround for some problem (don't recall which, though)

I remember having seen this -flag on some other templates...
For example firefox-esr and icecat.

from void-packages.

Issue is fixed.

from void-packages.