Invalid nullptr in QObject::connect

[Krzmbrzl]

Discussed in #6668

^{Originally posted by BenAicholtz December 14, 2024}
After building when I run mumble-server here is what I get

[[email protected] mumble-from-git-untouched]# ./mumble-server
qt.core.qobject.connect: QObject::connect(QObject, Unknown): invalid nullptr parameter

I am compiling this because mumble.com uses some different updates including SSL Timeout and AFK Channel abilities. Currently the error is happening without any changes on our side just the git current release.

1. git clone --depth 1 --recursive https://github.com/mumble-voip/mumble.git
2. cmake -Dclient=OFF
3. make
4. ./mumble-server

[[email protected] mumble-from-git-untouched]# cmake -Dclient=OFF
CMake Warning:
No source or binary directory provided. Both will be assumed to be the
same as the current working directory, but note that this warning will
become a fatal error in future CMake releases.

-- Found Python interpreter version 3.9.21
-- Using (among others) the following compiler flags: -Werror;-Wall;-Wpedantic;-Wextra;-Wconversion;-Wsign-conversion;-fsigned-char;-O3
-- ##################################################
-- Mumble version: 1.6.0
-- Architecture: x64
-- Build type: Release
-- Using LTO in release builds: ON
-- ##################################################
-- Qt6 component found: Core | Version: 6.6.2
-- Qt6 component found: Network | Version: 6.6.2
-- Qt6 component found: Xml | Version: 6.6.2
-- OpenSSL component found: Crypto | Version: 3.0.7
-- OpenSSL component found: SSL | Version: 3.0.7
-- TRACY_ENABLE: OFF
-- TRACY_ON_DEMAND: ON
-- TRACY_CALLSTACK: OFF
-- TRACY_NO_CALLSTACK: OFF
-- TRACY_NO_CALLSTACK_INLINES: OFF
-- TRACY_ONLY_LOCALHOST: OFF
-- TRACY_NO_BROADCAST: OFF
-- TRACY_ONLY_IPV4: OFF
-- TRACY_NO_CODE_TRANSFER: OFF
-- TRACY_NO_CONTEXT_SWITCH: OFF
-- TRACY_NO_EXIT: OFF
-- TRACY_NO_SAMPLING: OFF
-- TRACY_NO_VERIFY: OFF
-- TRACY_NO_VSYNC_CAPTURE: OFF
-- TRACY_NO_FRAME_IMAGE: OFF
-- TRACY_NO_SYSTEM_TRACING: OFF
-- TRACY_DELAYED_INIT: OFF
-- TRACY_MANUAL_LIFETIME: OFF
-- TRACY_FIBERS: OFF
-- TRACY_NO_CRASH_HANDLER: OFF
-- TRACY_TIMER_FALLBACK: OFF
-- Disabling warnings for targets: TracyClient
-- Tracy: OFF
-- Qt6 component found: Sql | Version: 6.6.2
-- File: /home/ben/svn/trunk/lsgmumble/mumble-1.5.735/mumble-from-git-untouched/src/murmur/murmur_autogen
-- Ice component found: Ice | Version: 3.7.10
-- Ice component found: IceSSL | Version: 3.7.10
-- Ice optional component found: IceDiscovery | Version: 3.7.10
-- Ice optional component found: IceLocatorDiscovery | Version: 3.7.10
-- Configuring done (1.5s)
-- Generating done (0.0s)
-- Build files have been written to: /home/ben/svn/trunk/lsgmumble/mumble-1.5.735/mumble-from-git-untouched

[Krzmbrzl]

Documenting for future reference: Defining the QT_FATAL_WARNINGS environment variable before running the executable makes any qWarning call a fatal error. This way, we can use a debugger to find the offending connect call more easily.

On my machine the Stack trace then is

#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3  0x00007ffff604526e in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4  0x00007ffff60288ff in __GI_abort () at ./stdlib/abort.c:79
#5  0x00007ffff6d0e0be in ??? () at /lib/x86_64-linux-gnu/libQt6Core.so.6
#6  0x00007ffff6d0e431 in QMessageLogger::warning(char const*, ...) const () at /lib/x86_64-linux-gnu/libQt6Core.so.6
#7  0x00007ffff6c23247 in ??? () at /lib/x86_64-linux-gnu/libQt6Core.so.6
#8  0x00007ffff6c1ffd1 in QObjectPrivate::connectImpl(QObject const*, int, QObject const*, void**, QtPrivate::QSlotObjectBase*, int, int const*, QMetaObject const*) () at /lib/x86_64-linux-gnu/libQt6Core.so.6
#9  0x00007ffff6c2024f in QObject::connectImpl(QObject const*, void**, QObject const*, void**, QtPrivate::QSlotObjectBase*, Qt::ConnectionType, int const*, QMetaObject const*) () at /lib/x86_64-linux-gnu/libQt6Core.so.6
#10 0x00007ffff6f622f9 in ??? () at /lib/x86_64-linux-gnu/libQt6Network.so.6
#11 0x00007ffff6f22ef7 in QTlsBackend::availableBackendNames() () at /lib/x86_64-linux-gnu/libQt6Network.so.6
#12 0x00007ffff6f234e3 in QTlsBackend::defaultBackendName() () at /lib/x86_64-linux-gnu/libQt6Network.so.6
#13 0x00007ffff6f08fd4 in QSslSocketPrivate::tlsBackendInUse() () at /lib/x86_64-linux-gnu/libQt6Network.so.6
#14 0x00007ffff6f00183 in QSslSocketPrivate::supportsSsl() () at /lib/x86_64-linux-gnu/libQt6Network.so.6
#15 0x00007ffff6f0023d in QSslSocketPrivate::ensureInitialized() () at /lib/x86_64-linux-gnu/libQt6Network.so.6
#16 0x00007ffff6f1ebbe in ??? () at /lib/x86_64-linux-gnu/libQt6Network.so.6
#17 0x00007ffff6f1ee60 in QSslCertificate::QSslCertificate(QByteArray const&, QSsl::EncodingFormat) () at /lib/x86_64-linux-gnu/libQt6Network.so.6
#18 0x00005555555f2894 in MetaParams::MetaParams (this=0x5555557f6400 <Meta::mp>) at /home/robert/Documents/Git/mumble/src/murmur/Meta.cpp:46
#19 0x00005555555f30e4 in __static_initialization_and_destruction_0 () at /usr/include/boost/optional/optional.hpp:104
#20 0x00005555555f371c in _GLOBAL__sub_I__ZN4Meta2mpE () at /home/robert/Documents/Git/mumble/src/murmur/Meta.cpp:781
#21 0x00007ffff602a304 in call_init (env=<optimized out>, argv=0x7fffffffd798, argc=1) at ../csu/libc-start.c:145
#22 __libc_start_main_impl (main=0x5555555c83b3 <main(int, char**)>, argc=1, argv=0x7fffffffd798, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd788) at ../csu/libc-start.c:347
#23 0x00005555555bde75 in _start ()

This makes me believe that this is not due a connect call in Mumble itself. In fact, this looks suspiciously similar to https://bugreports.qt.io/browse/QTBUG-104833, where it is mentioned that this is because the QApplication must be the first QObject to be created in any application. I think with MetaParams being a static member of the Meta class, this almost certainly causes the constructor of MetaParams to run before we create the QApplication in the main function.

@davidebeatrici @Hartmnt do you agree with my reasoning?

I think the easiest fix might be to use lazy-loading for the meta parameters or make mp a pointer-like type such that we can take active control over when it is instantiated from within the main function.

[BenAicholtz]

Is there any modification you would like me to test? Happy to. Appreciate your help!

[davidebeatrici]

@Krzmbrzl I fully agree with your investigation. It's generally good practice to only use static objects when strictly necessary, in my opinion we should definitely use a (smart) pointer.

@BenAicholtz We'll let you know as soon as the modification is ready to test, thank you for reporting the issue!