GTKMM4 app is crashing on calling window hide() - c++

In my ubuntu 20.04 and Windows 10, I installed GTKMM4 with VCPKG since the normal installation of GTKMM4 is not available.
Then I downloaded this example from the gnome tutorial page and added this cmake.
On clicking the close button, which calls the window hide, the app is crashing in Ubuntu alone and no issue is there in windows setup.
The backtrace is given below.
Thread 1 "gtkmmtes2" received signal SIGSEGV, Segmentation fault.
0x00007ffff7146ad4 in g_str_hash () from /root/programs/vcpkg//packages/gtk_x64-linux/lib/libgtk-4.so.1
(gdb) bt
#0 0x00007ffff7146ad4 in g_str_hash () from /root/programs/vcpkg//packages/gtk_x64-linux/lib/libgtk-4.so.1
#1 0x00007ffff7145c5c in g_hash_table_contains () from /root/programs/vcpkg//packages/gtk_x64-linux/lib/libgtk-4.so.1
#2 0x00007ffff70369e8 in gtk_at_spi_cache_remove_context () from /root/programs/vcpkg//packages/gtk_x64-linux/lib/libgtk-4.so.1
#3 0x00007ffff70395c4 in gtk_at_spi_context_unrealize () from /root/programs/vcpkg//packages/gtk_x64-linux/lib/libgtk-4.so.1
#4 0x00007ffff6d08f87 in gtk_at_context_unrealize () from /root/programs/vcpkg//packages/gtk_x64-linux/lib/libgtk-4.so.1
#5 0x00007ffff6f7c7f9 in gtk_window_unmap () from /root/programs/vcpkg//packages/gtk_x64-linux/lib/libgtk-4.so.1
#6 0x0000555555741304 in Gtk::Widget_Class::unmap_callback(_GtkWidget*) ()
#7 0x00007ffff7229abe in g_closure_invoke () from /root/programs/vcpkg//packages/gtk_x64-linux/lib/libgtk-4.so.1
#8 0x00007ffff723fe39 in signal_emit_unlocked_R () from /root/programs/vcpkg//packages/gtk_x64-linux/lib/libgtk-4.so.1
#9 0x00007ffff724cafd in g_signal_emit_valist () from /root/programs/vcpkg//packages/gtk_x64-linux/lib/libgtk-4.so.1
#10 0x00007ffff724cfc3 in g_signal_emit () from /root/programs/vcpkg//packages/gtk_x64-linux/lib/libgtk-4.so.1
#11 0x00007ffff6f6069a in gtk_widget_unmap () from /root/programs/vcpkg//packages/gtk_x64-linux/lib/libgtk-4.so.1
#12 0x00007ffff6f7c869 in gtk_window_hide () from /root/programs/vcpkg//packages/gtk_x64-linux/lib/libgtk-4.so.1
#13 0x00005555557417dd in Gtk::Widget_Class::hide_callback(_GtkWidget*) ()
#14 0x00007ffff7229abe in g_closure_invoke () from /root/programs/vcpkg//packages/gtk_x64-linux/lib/libgtk-4.so.1
#15 0x00007ffff723fe39 in signal_emit_unlocked_R () from /root/programs/vcpkg//packages/gtk_x64-linux/lib/libgtk-4.so.1
#16 0x00007ffff724cafd in g_signal_emit_valist () from /root/programs/vcpkg//packages/gtk_x64-linux/lib/libgtk-4.so.1
#17 0x00007ffff724cfc3 in g_signal_emit () from /root/programs/vcpkg//packages/gtk_x64-linux/lib/libgtk-4.so.1
#18 0x00007ffff6f6bbbc in gtk_widget_hide () from /root/programs/vcpkg//packages/gtk_x64-linux/lib/libgtk-4.so.1
#19 0x000055555572a064 in ExampleWindow::on_action_file_quit() ()
#20 0x000055555572d3ed in void std::__invoke_impl<void, void (ExampleWindow::* const&)(), ExampleWindow&>(std::__invoke_memfun_ref, void (ExampleWindow::* const&)(), ExampleWindow&) ()
#21 0x000055555572d0fc in std::__invoke_result<void (ExampleWindow::* const&)(), ExampleWindow&>::type std::__invoke<void (ExampleWindow::* const&)(), ExampleWindow&>(void (ExampleWindow::* const&)(), ExampleWindow&) ()
The issue is easily reproducible with any window and hide() function in Ubuntu.
Also I'm seeing the following warnings with every gtkmm4 app in Ubuntu.
(gtkmmtes2:567918): GLib-GIO-CRITICAL **: 09:24:41.966: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed
Components installed with VCPKG
root#renju-ubuntu:~# vcpkg list
atk:x64-linux 2.38.0#3 GNOME Accessibility Toolkit
atkmm:x64-linux 2.36.1 atkmm is the official C++ interface for the ATK ...
brotli:x64-linux 1.0.9#3 a generic-purpose lossless compression algorithm...
bzip2:x64-linux 1.0.8#3 bzip2 is a freely available, patent free, high-q...
bzip2[tool]:x64-linux Builds bzip2 executable
cairo:x64-linux 1.17.6#4 Cairo is a 2D graphics library with support for ...
cairo[fontconfig]:x64-linux build with fontconfig
cairo[freetype]:x64-linux use the freetype font backend
cairo[gobject]:x64-linux build gobject module
cairo[x11]:x64-linux build with x11 support
cairomm:x64-linux 1.16.2#1 A C++ wrapper for the cairo graphics library
dirent:x64-linux 1.23.2#1 Dirent is a C/C++ programming interface that all...
egl-registry:x64-linux 2022-09-20 the EGL API and Extension Registry
expat:x64-linux 2.5.0#1 XML parser library written in C
fontconfig:x64-linux 2.14.1 Library for configuring and customizing font acc...
freetype:x64-linux 2.12.1#2 A library to render fonts.
freetype[brotli]:x64-linux Support decompression of WOFF2 streams
freetype[bzip2]:x64-linux Support bzip2 compressed fonts.
freetype[png]:x64-linux Support PNG compressed OpenType embedded bitmaps.
freetype[zlib]:x64-linux Use zlib instead of internal library for DEFLATE
fribidi:x64-linux 1.0.12 GNU FriBidi is an implementation of the Unicode ...
gdk-pixbuf:x64-linux 2.42.9#3 Image loading library.
getopt:x64-linux 0#2 The getopt and getopt_long functions automate so...
gettext:x64-linux 0.21#9 GNU gettext provides libintl and a set of tools ...
gettext[tools]:x64-linux Build gettext tools
glib:x64-linux 2.74.1 Portable, general-purpose utility library.
glibmm:x64-linux 2.74.0 This is glibmm, a C++ API for parts of glib that...
gperf:x64-linux 3.1#4 GNU perfect hash function generator
graphene:x64-linux 1.10.8 A thin layer of types for graphic libraries.
gtk:x64-linux 4.6.8 Portable library for creating graphical user int...
gtkmm:x64-linux 4.6.0 gtkmm is the official C++ interface for the popu...
harfbuzz:x64-linux 5.0.1#3 HarfBuzz OpenType text shaping engine
libepoxy:x64-linux 1.5.10#1 Epoxy is a library for handling OpenGL function ...
libffi:x64-linux 3.4.4 Portable, high level programming interface to va...
libiconv:x64-linux 1.17 GNU Unicode text conversion
libjpeg-turbo:x64-linux 2.1.4 libjpeg-turbo is a JPEG image codec that uses SI...
liblzma:x64-linux 5.2.5#6 Compression library with an API similar to that ...
libpng:x64-linux 1.6.38 libpng is a library implementing an interface fo...
libsass:x64-linux 3.6.5#1 LibSass - Sass compiler written in C++
libsigcpp-3:x64-linux 3.0.3#1 Typesafe callback framework for C++
libsigcpp:x64-linux 3.2.0 Typesafe callback framework for C++
libuuid:x64-linux 1.0.3#11 Universally unique id library
lzo:x64-linux 2.10#7 Lossless data compression library
pango:x64-linux 1.50.11 Text and font handling library.
pangomm:x64-linux 2.50.1 pangomm is the official C++ interface for the Pa...
pcre2:x64-linux 10.40#1 Regular Expression pattern matching using the sa...
pcre:x64-linux 8.45#5 Perl Compatible Regular Expressions
pixman:x64-linux 0.40.0#4 Pixman is a low-level software library for pixel...
pthread:x64-linux 3.0.0#1 empty package, linking to other port
pthreads:x64-linux 3.0.0#12 Meta-package that provides PThreads4W on Windows...
sassc:x64-linux 3.6.2 SassC is a wrapper around libsass (http://github...
tiff:x64-linux 4.4.0#1 A library that supports the manipulation of TIFF...
tiff[jpeg]:x64-linux Support JPEG compression in TIFF image files
tiff[lzma]:x64-linux Support LZMA compression in TIFF image files
tiff[zip]:x64-linux Support ZIP/deflate compression in TIFF image files
vcpkg-cmake-config:x64-linux 2022-02-06#1
vcpkg-cmake:x64-linux 2022-10-30
vcpkg-tool-meson:x64-linux 0.63 Meson build system
zlib:x64-linux 1.2.13 A compression library

Related

Can't see symbols from Erlang NIF library in core file

I'm working on an Erlang wrapper over a 3rd party C library on Ubuntu Linux on x86, so I'm creating a NIF. Sometimes my code (I think) crashes, resulting in a core file. Unfortunately the stacktrace is not really helpful:
(gdb) bt
#0 0x00007fc22229968a in ?? ()
#1 0x0000000060e816d8 in ?? ()
#2 0x0000000007cd48b0 in ?? ()
#3 0x00007fc228031410 in ?? ()
#4 0x00007fc228040b80 in ?? ()
#5 0x00007fc228040c50 in ?? ()
#6 0x00007fc22223de0b in ?? ()
#7 0x0000000000000000 in ?? ()
even though I built my NIF .so file with debug info:
ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=b70dd1f2450f5c0e9980c8396aaad2e1cd29024c, with debug_info, not stripped
The beam also has debug info:
ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=e0a5dba6507b8c2b333faebc89fbc6ea2f7263b9, for GNU/Linux 3.2.0, with debug_info, not stripped
However, info sharedlibrary doesn't show neither the NIF nor the 3rd party lib:
(gdb) info sharedlibrary
From To Syms Read Shared Object Library
0x00007fc28942ed50 0x00007fc289432004 Yes /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0
0x00007fc289429220 0x00007fc28942a179 Yes /lib/x86_64-linux-gnu/libdl.so.2
0x00007fc2892e83c0 0x00007fc28938ef18 Yes /lib/x86_64-linux-gnu/libm.so.6
0x00007fc2892b76a0 0x00007fc2892c517c Yes /lib/x86_64-linux-gnu/libtinfo.so.6
0x00007fc28928dae0 0x00007fc28929d4d5 Yes /lib/x86_64-linux-gnu/libpthread.so.0
0x00007fc2890b9630 0x00007fc28922e20d Yes /lib/x86_64-linux-gnu/libc.so.6
0x00007fc289657100 0x00007fc289679674 Yes (*) /lib64/ld-linux-x86-64.so.2
0x00007fc24459c040 0x00007fc2445ab8ad Yes /home/nar/otp/23.3.4.2/lib/crypto-4.9.0.2/priv/lib/crypto.so
0x00007fc2239e3000 0x00007fc223b7c800 Yes (*) /lib/x86_64-linux-gnu/libcrypto.so.1.1
0x00007fc2896500e0 0x00007fc28965028c Yes /home/nar/otp/23.3.4.2/lib/crypto-4.9.0.2/priv/lib/crypto_callback.so
0x00007fc289649380 0x00007fc28964bc1c Yes /home/nar/otp/23.3.4.2/lib/asn1-5.0.15/priv/lib/asn1rt_nif.so
0x00007fc289638720 0x00007fc28963bd70 Yes /lib/x86_64-linux-gnu/librt.so.1
I found this answer mentioning that "The Erlang VM doesn't load NIF libraries with global symbols exposed". Could this be the reason why I don't see the symbols? Is there a way to tell gdb to look up symbols from my .so file?
I built the Erlang VM with debug enabled (I used kerl to build and set KERL_BUILD_DEBUG_VM to true), then started the erlang with the -debug option. This way some asserts were seem to be enabled in the code, they crashed and that lead to me to the bugs in my code. Since then I don't have the crashes.

Crash when running QT application on Ubuntu Server

I am seeing that if I run a QT application on Ubuntu desktop edition I am able to run the application. If I take the same application and try and run it on Ubuntu server edition I am seeing a crash when starting the QT application. So far I have seen that I need to set QT to render offscreen with setting this environmental variable:
export QT_QPA_PLATFORM=offscreen
And then when I run the application I get this stack trace with the application crashing:
Thread 3 "hmi" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7fa8700 (LWP 18084)]
0x00007fffdf88decb in ?? () from /Qt5.6.2/5.6/gcc_64/plugins/platforms/libqoffscreen.so
(gdb) bt
#0 0x00007fffdf88decb in ?? () from /Qt5.6.2/5.6/gcc_64/plugins/platforms/libqoffscreen.so
#1 0x00007fffdf88e283 in ?? () from /Qt5.6.2/5.6/gcc_64/plugins/platforms/libqoffscreen.so
#2 0x00007ffff399a78d in QOpenGLContext::create() () from /Qt5.6.2/5.6/gcc_64/lib/libQt5Gui.so.5
#3 0x00007ffff41d2a67 in ?? () from /Qt5.6.2/5.6/gcc_64/lib/libQt5Quick.so.5
#4 0x00007ffff41d32d2 in ?? () from /Qt5.6.2/5.6/gcc_64/lib/libQt5Quick.so.5
#5 0x00007ffff39633ea in QWindow::event(QEvent*) () from /Qt5.6.2/5.6/gcc_64/lib/libQt5Gui.so.5
#6 0x00007ffff4206553 in QQuickWindow::event(QEvent*) () from /Qt5.6.2/5.6/gcc_64/lib/libQt5Quick.so.5
#7 0x00007ffff4eb25ca in QCoreApplication::notify(QObject*, QEvent*) () from /Qt5.6.2/5.6/gcc_64/lib/libQt5Core.so.5
#8 0x00007ffff4eb2720 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /Qt5.6.2/5.6/gcc_64/lib/libQt5Core.so.5
#9 0x00007ffff3958c69 in QGuiApplicationPrivate::processExposeEvent(QWindowSystemInterfacePrivate::ExposeEvent*) () from /Qt5.6.2/5.6/gcc_64/lib/libQt5Gui.so.5
#10 0x00007ffff39597fd in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) () from /Qt5.6.2/5.6/gcc_64/lib/libQt5Gui.so.5
#11 0x00007ffff393aad3 in QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /Qt5.6.2/5.6/gcc_64/lib/libQt5Gui.so.5
#12 0x00007fffdf88e3f0 in ?? () from /Qt5.6.2/5.6/gcc_64/plugins/platforms/libqoffscreen.so
#13 0x00007fffe9eb3197 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00007fffe9eb33f0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x00007fffe9eb349c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#16 0x00007ffff4f01f07 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /Qt5.6.2/5.6/gcc_64/lib/libQt5Core.so.5
#17 0x00007ffff4eb076a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /Qt5.6.2/5.6/gcc_64/lib/libQt5Core.so.5
#18 0x00007ffff4eb85fd in QCoreApplication::exec() () from /Qt5.6.2/5.6/gcc_64/lib/libQt5Core.so.5
I take the same application and run with offscreen set and on the desktop edition I am not seeing the same crash. I do not see much info about the QT library libqoffscreen.so and cannot find symbols for the prebuilt libraries to get a better stack trace. Is there anything that I may need to install on the Ubuntu server to allow me to run this QT application?
You’re trying to use Qt Quick, and this won’t work with the offscreen platform, as there’s no OpenGL support there. I don’t understand why you’d want to run such an application headless – it won’t be useful, presumably. Since it your code, you shouldn’t be showing the GUI in the headless mode: either add a command option to start without the GUI, or disable the GUI code using compile options (e.g. a macro passed from the makefile).

Protobuf version conflicts with Qt

I'm trying to use protobufs v 3.3.2 with Qt 5.9.1. This works with some Qt applications, but only if they are command line programs. Once I create a GUI application with Qt and protobufs, I get this error:
[libprotobuf FATAL
/home/mkraus/Documents/dev/star385/build/linux-desktop-debug-libs/protobuf/src/src/google/protobuf/stubs/common.cc:78]
This program was compiled against version 2.6.1 of the Protocol Buffer runtime library, which is not compatible with the installed
version (3.3.2). Contact the program author for an update. If you
compiled the program yourself, make sure that your headers are from
the same version of Protocol Buffers as your link-time library.
(Version verification failed in
"/build/mir-ui6vjS/mir-0.26.3+16.04.20170605/obj-x86_64-linux-gnu/src/protobuf/mir_protobuf.pb.cc".)
I should clarify that my part of the code is certainly using version 3.3.2 (I'm downloading and compiling protobufs from the git sources and statically linking). Look at the stack trace below to see that something that Qt is referencing is causing a protobuf version mismatch.
I'm developing on Ubuntu 16.04 and using the default desktop environment (Unity).
Work-Arounds
My troubleshooting has revealed these symptoms and work-arounds:
Use KDE / KUbuntu. Changing the desktop environment when logging in completely avoids the version mismatch issue.
Run the Qt application with -platform eglfs. This runs the application in full-screen mode using OpenGL. The program runs, but the window size is incorrect. When using the -platform eglfs option, it works even in Unity, but without this option, it gives me the above error.
Any Qt application that is a command-line only application (using QCoreApplication instead of QGuiApplication) can use protobufs 3.3.2. Changing the same app to use a GUI causes the version mismatch issue.
Questions
How can I use protobufs 3.3.2 with Qt GUI applications, and also not be dependent on what desktop environment is in use? Is it Qt that is using the version 2.6.1 of protobufs, and if so, is it feasible to compile Qt to use protobufs 3.3.2?
Debug Info
Here is a stack trace (the program crashes almost immediately upon starting):
terminate called after throwing an instance of 'google::protobuf::FatalException'
what(): This program was compiled against version 2.6.1 of the Protocol Buffer runtime library, which is not compatible with the installed version (3.3.2). Contact the program author for an update. If you compiled the program yourself, make sure that your headers are from the same version of Protocol Buffers as your link-time library. (Version verification failed in "/build/mir-ui6vjS/mir-0.26.3+16.04.20170605/obj-x86_64-linux-gnu/src/protobuf/mir_protobuf.pb.cc".)
Thread 1 "scan" received signal SIGABRT, Aborted.
0x00007ffff4dff428 in __GI_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x00007ffff4dff428 in __GI_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1 0x00007ffff4e0102a in __GI_abort () at abort.c:89
#2 0x00007ffff543984d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007ffff54376b6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007ffff5437701 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007ffff5437919 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x0000000000603e0a in google::protobuf::internal::LogMessage::Finish (this=0x7fffffffc250)
at /home/mkraus/Documents/dev/star385/build/linux-desktop-debug-libs/protobuf/src/src/google/protobuf/stubs/common.cc:268
#7 0x0000000000603e5a in google::protobuf::internal::LogFinisher::operator= (this=0x7fffffffc20f, other=...)
at /home/mkraus/Documents/dev/star385/build/linux-desktop-debug-libs/protobuf/src/src/google/protobuf/stubs/common.cc:276
#8 0x0000000000603171 in google::protobuf::internal::VerifyVersion (headerVersion=2006001, minLibraryVersion=2006000,
filename=0x7fffde80aec0 "/build/mir-ui6vjS/mir-0.26.3+16.04.20170605/obj-x86_64-linux-gnu/src/protobuf/mir_protobuf.pb.cc")
at /home/mkraus/Documents/dev/star385/build/linux-desktop-debug-libs/protobuf/src/src/google/protobuf/stubs/common.cc:86
#9 0x00007fffde7d490b in mir::protobuf::protobuf_AddDesc_mir_5fprotobuf_2eproto() ()
from /usr/lib/x86_64-linux-gnu/libmirprotobuf.so.3
#10 0x00007fffde7d2409 in ?? () from /usr/lib/x86_64-linux-gnu/libmirprotobuf.so.3
#11 0x00007ffff7de76ba in call_init (l=<optimized out>, argc=argc#entry=1, argv=argv#entry=0x7fffffffd5d8,
env=env#entry=0x7fffffffd5e8) at dl-init.c:72
#12 0x00007ffff7de77cb in call_init (env=0x7fffffffd5e8, argv=0x7fffffffd5d8, argc=1, l=<optimized out>) at dl-init.c:30
#13 _dl_init (main_map=main_map#entry=0xa2f450, argc=1, argv=0x7fffffffd5d8, env=0x7fffffffd5e8) at dl-init.c:120
#14 0x00007ffff7dec8e2 in dl_open_worker (a=a#entry=0x7fffffffc6e0) at dl-open.c:575
#15 0x00007ffff7de7564 in _dl_catch_error (objname=objname#entry=0x7fffffffc6d0, errstring=errstring#entry=0x7fffffffc6d8,
mallocedp=mallocedp#entry=0x7fffffffc6cf, operate=operate#entry=0x7ffff7dec4d0 <dl_open_worker>, args=args#entry=0x7fffffffc6e0)
at dl-error.c:187
#16 0x00007ffff7debda9 in _dl_open (file=0xa2f048 "/opt/Qt5.8.0/5.8/gcc_64/plugins/platformthemes/libqgtk3.so", mode=-2147479551,
caller_dlopen=0x7ffff599b7a8, nsid=-2, argc=<optimized out>, argv=<optimized out>, env=0x7fffffffd5e8) at dl-open.c:660
#17 0x00007ffff1806f09 in dlopen_doit (a=a#entry=0x7fffffffc910) at dlopen.c:66
#18 0x00007ffff7de7564 in _dl_catch_error (objname=0xa02b80, errstring=0xa02b88, mallocedp=0xa02b78,
operate=0x7ffff1806eb0 <dlopen_doit>, args=0x7fffffffc910) at dl-error.c:187
#19 0x00007ffff1807571 in _dlerror_run (operate=operate#entry=0x7ffff1806eb0 <dlopen_doit>, args=args#entry=0x7fffffffc910)
at dlerror.c:163
#20 0x00007ffff1806fa1 in __dlopen (file=<optimized out>, mode=<optimized out>) at dlopen.c:87
#21 0x00007ffff599b7a8 in ?? () from /opt/Qt5.8.0/5.8/gcc_64/lib/libQt5Core.so.5
#22 0x00007ffff5994fd5 in ?? () from /opt/Qt5.8.0/5.8/gcc_64/lib/libQt5Core.so.5
#23 0x00007ffff598a647 in QFactoryLoader::instance(int) const () from /opt/Qt5.8.0/5.8/gcc_64/lib/libQt5Core.so.5
#24 0x00007ffff6b392f1 in ?? () from /opt/Qt5.8.0/5.8/gcc_64/lib/libQt5Gui.so.5
#25 0x00007ffff6b43538 in QGuiApplicationPrivate::createPlatformIntegration() () from /opt/Qt5.8.0/5.8/gcc_64/lib/libQt5Gui.so.5
#26 0x00007ffff6b43edd in QGuiApplicationPrivate::createEventDispatcher() () from /opt/Qt5.8.0/5.8/gcc_64/lib/libQt5Gui.so.5
#27 0x00007ffff59a57d6 in QCoreApplicationPrivate::init() () from /opt/Qt5.8.0/5.8/gcc_64/lib/libQt5Core.so.5
#28 0x00007ffff6b456ab in QGuiApplicationPrivate::init() () from /opt/Qt5.8.0/5.8/gcc_64/lib/libQt5Gui.so.5
#29 0x00007ffff6b46364 in QGuiApplication::QGuiApplication(int&, char**, int) () from /opt/Qt5.8.0/5.8/gcc_64/lib/libQt5Gui.so.5
#30 0x00000000005c55bd in main (argc=1, argv=0x7fffffffd5d8) at /home/mkraus/Documents/dev/star385/src/linux/ui/scan/main.cpp:35
You can find here a discussion about the same issue and they talk about an interesting workaround.
It seems that this error is caused by the library libqgtk3.so located in /opt/Qt/5.9/gcc_64/plugins/platformthemes. If you don't need it in your project you can rename/remove it to make the error go away.
If you are using CMake as a build system you also need to comment all the lines in the file /opt/Qt/5.9/gcc_64/lib/cmake/Qt5Gui/Qt5Gui_QGtk3ThemePlugin.cmake to avoid configure issues.
To add on, the real problem comes from the library libmir which depends on the the libprotobuf. You may run on this problem whenever you try to use recent tensorflow with libgtk3.0 because of this hard dependency. As libmir depends on the system libprotobuf which is normally behind the version in use by tensorflow (which downloads its own version from the repository).
The good news, this BUG on libgtk was reported and fixed however, to use the fixed version you have to move to libgtk3.0 3.22 (see BUG report).
If you are using Qt from the Ubuntu package repository, you can remove the offending library by uninstalling qt5-gtk-platformtheme. This will remove libqgtk3.so and the corresponding CMake file without having to resort to hacks that might have unintended consequences.
As Blabdouze said, this error is caused by the libqgtk3 plugin which is used to set the GUI style. libqgtk3 uses the libmir system library, which uses protobuf 2.6.1. This leads to conflicts when the application starts.
I found a workaround that allows you to avoid editing of Qt files:
You need to copy the "plugins" folder from ".../Qt/5.хх.хх/gcc_64/" to some other location (for example, next to the project build folder).
Then you must remove "platformthemes/libqgtk3.so" and "platformthemes/libqgtk3.so.debug" from the copied folder.
In main(), before creating a QApplication instance, call the static function "QApplication::setLibraryPaths("path/to/copied/plugins/folder")".
Finally, you must add variable "LD_LIBRARY_PATH" with the value ".../Qt/5.хх.хх/gcc_64/lib" (correct path will depend on your Qt version) in a project's "environment settings" in Qt Creator. You also may add a "QT_DEBUG_PLUGINS" variable with a value of "1". It will allow you to check which plugins are used by your project and remove unnecessary plugins from the release version.
In conclusion I would like to note that this error occurred when running the project in Ubuntu 16.04, but it disappeared when I switched to version 18.04. It seems that in version 18.04 app uses the default Qt style instead of the GTK style.

Segfault during static initialization when linking gcc-built Boost into an Intel C++-compiled program

I have an Ubuntu 13.04 system with the latest SVN version of the Boost C++ libraries installed. The Boost installation was built using the system's native gcc version, v4.7.3. I use Boost pretty extensively, and it works very well when I compile using gcc; I have used many of them, including Boost.Thread (which I will talk about more below), without any issues.
My problem occurs if I try to build a program using the Intel C++ compiler (I've personally used a few different versions in the v13.x series) that link with the installed Boost libraries. When I do so, I get a segmentation fault immediately after program startup; it appears to occur during static initialization of the Boost.Thread library. Here's a simple example program:
#include <boost/version.hpp>
#include <boost/thread.hpp>
int main()
{
boost::this_thread::sleep(boost::posix_time::seconds(1));
}
I compile it using Intel C++:
icpc test.cc -lboost_thread -lboost_system -I/path/to/boost/inc/dir -L/path/to/boost/lib/dir
As I said, when I run the resulting program, I get a near-immediate segfault. Via gdb, the stack trace from the point of the segfault is as follows:
#0 0x00007ffff79b6351 in boost::exception_ptr boost::exception_detail::get_static_exception_object<boost::exception_detail::bad_exception_>() () from ./libboost_thread.so.1.55.0
#1 0x00007ffff79b02e1 in _GLOBAL__sub_I_thread.cpp () from ./libboost_thread.so.1.55.0
#2 0x00007ffff7de9876 in call_init (l=l#entry=0x7ffff7ff9a10, argc=argc#entry=1,
argv=argv#entry=0x7fffffffe0b8, env=env#entry=0x7fffffffe0c8) at dl-init.c:84
#3 0x00007ffff7de9930 in call_init (env=<optimized out>, argv=<optimized out>,
argc=<optimized out>, l=0x7ffff7ff9a10) at dl-init.c:55
#4 _dl_init (main_map=0x7ffff7ffe268, argc=1, argv=0x7fffffffe0b8, env=0x7fffffffe0c8)
at dl-init.c:133
#5 0x00007ffff7ddb68a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#6 0x0000000000000001 in ?? ()
#7 0x00007fffffffe391 in ?? ()
#8 0x0000000000000000 in ?? ()
Not very enlightening, but it's clearly dying during the initialization of libboost_thread.so. If I rebuild Boost including debug symbols, then I get a slightly better picture:
#0 shared_count (r=..., this=0x7ffff7bbc5f8 <boost::exception_ptr boost::exception_detail::get_static_exception_object<boost::exception_detail::bad_exception_>()::ep+8>)
at ./boost/smart_ptr/shared_ptr.hpp:328
#1 shared_ptr (this=0x7ffff7bbc5f0 <boost::exception_ptr boost::exception_detail::get_static_exception_object<boost::exception_detail::bad_exception_>()::ep>) at ./boost/smart_ptr/shared_ptr.hpp:328
#2 exception_ptr (ptr=..., this=0x7ffff7bbc5f0 <boost::exception_ptr boost::exception_detail::get_static_exception_object<boost::exception_detail::bad_exception_>()::ep>)
at ./boost/exception/detail/exception_ptr.hpp:53
#3 boost::exception_detail::get_static_exception_object<boost::exception_detail::bad_exception_> () at ./boost/exception/detail/exception_ptr.hpp:130
#4 0x00007ffff79b02e1 in __static_initialization_and_destruction_0 (__initialize_p=<optimized out>, __priority=<optimized out>) at ./boost/exception/detail/exception_ptr.hpp:143
#5 _GLOBAL__sub_I_thread.cpp(void) () at libs/thread/src/pthread/thread.cpp:767
#6 0x00007ffff7de9876 in call_init (l=l#entry=0x7ffff7ff9a10, argc=argc#entry=1, argv=argv#entry=0x7fffffffe0b8, env=env#entry=0x7fffffffe0c8) at dl-init.c:84
#7 0x00007ffff7de9930 in call_init (env=<optimized out>, argv=<optimized out>, argc=<optimized out>, l=0x7ffff7ff9a10) at dl-init.c:55
#8 _dl_init (main_map=0x7ffff7ffe268, argc=1, argv=0x7fffffffe0b8, env=0x7fffffffe0c8) at dl-init.c:133
#9 0x00007ffff7ddb68a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#10 0x0000000000000001 in ?? ()
#11 0x00007fffffffe391 in ?? ()
#12 0x0000000000000000 in ?? ()
It's unclear to me what static/global object is causing the problem to occur, so I'm not sure how to proceed. I have duplicated this behavior using a number of Boost versions and a few different versions of the Intel C++ compiler in the v13.x series, which is the only release that I have access to at the moment. I have tried every compiler permutation (i.e. I have built Boost with both gcc and icpc and I've built my test application with both also); the only permutation that fails is where Boost is built with gcc and my test application is built using icpc. In every other case, the test application runs successfully.
With that said, you might be led to the obvious answer:
Why not just rebuild Boost using icpc and call it a day? That approach would seem to be effective, given my experimentation, but I have customers who like to use icpc to build my software. Those same customers are likely to have a Linux-distro-provided Boost package installed; they do not have any control over the build environment that was used to generate that package (and, in all likelihood, it was compiled using gcc anyway). Therefore, if it is possible to support such a mixed-compiler configuration, that would be optimal.
Does anyone have any recommendations as to how I might address this static initialization issue?
This is a long shot, but... If you have a different g++ in your PATH than the one used to build the Boost libraries, get rid of it or pass -gxx-name /usr/bin/g++ to icpc. (The Intel compiler adapts itself to the version of GCC it thinks you are using. -gxx-name lets you force the issue.)
OK that probably did not help.
Ubuntu 13.04 is not supported prior to Intel Composer XE 2013 SP1, aka. compiler version 14.0.0. See the "System Requirements" section of the Release Notes and compare it to the same section for the last 13.x release.
Intel definitely aims for link compatibility with GCC. If you can reproduce this problem on a clean install of a supported version of Linux, you should be able to submit a support ticket and get it fixed.

How to use mfc in de dll using def file

I'm writing a plugin for a musicplayer named MusicBee.
I got one problem writing it. I must use mfc for a lot of thinks. Such as hbitmap, special timers and other stuff. But every time I change "Use of MFC" in VS2012 from "Use standard Windows library" to "use mfc ..." my code doenst compile. The problem is a def file that I must use for the plugin of MusicBee.
The def file looks like:
LIBRARY "mb_LogitechPlugin"
EXPORTS
Initialise #1
Configure #2
Close #3
Uninstall #4
ReceiveNotification #5
RetrieveLyrics #6
RetrieveArtwork #7
SaveSettings #8
Refresh #9
IsReady #10
GetIcon #11
FolderExists #12
GetFolders #13
GetFiles #14
FileExists #15
GetFile #16
GetFileArtwork #17
GetPlaylists #18
GetPlaylistFiles #19
GetStream #20
GetError #21
All other code can be found at:
https://bitbucket.org/jimmyD/musicbee-logitech-applet/src
You do not have to use MFC at all.
MFC (Microsoft Foundation Classes) are nothing more than a (bad) wrapper around the Win32 API. you do not need to use it all. If there are special things that MFC is doing for you that you cannot figure out, I suggest that you look at the included MFC source. It really is not worth it, just to get at HBITMAP or some other things.