Slackware64-current, Virtualbox 6.1.x testbuilds segfault

Discussions related to using VirtualBox on Linux hosts.
Post Reply
slvr32
Posts: 13
Joined: 14. Feb 2019, 04:09

Slackware64-current, Virtualbox 6.1.x testbuilds segfault

Post by slvr32 »

I have a pure (not 32/64-bit multi-lib) 64-bit Slackware64-current (20210320) install, and it seems that any recent testbuilds of VirtualBox 6.1.x segfault with the following...

$ virtualbox

(process:27731): GLib-GObject-WARNING **: 23:21:10.670: cannot register existing type 'NMAgentManagerError'

(process:27731): GLib-CRITICAL **: 23:21:10.670: g_once_init_leave: assertion 'result != 0' failed

(process:27731): GLib-GObject-WARNING **: 23:21:10.670: cannot retrieve class for invalid (unclassed) type '<invalid>'
Segmentation fault

The common temporary fix is to disable auto-update in VirtualBox, which avoids the segfault/crash, and allows VirtualBox to start, but checking for updates manually will cause the same segfault/crash.

$ VBoxManage setextradata global GUI/UpdateDate never

Any ideas for further troubleshooting?
Last edited by slvr32 on 27. Mar 2021, 18:35, edited 3 times in total.
slvr32
Posts: 13
Joined: 14. Feb 2019, 04:09

Re: Slackware64-current, Virtualbox 6.1.x testbuilds segfault

Post by slvr32 »

Bump for attention, to try to figure out the culprit of this segfault/crash.
fth0
Volunteer
Posts: 5668
Joined: 14. Feb 2019, 03:06
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Linux, Windows 10, ...
Location: Germany

Re: Slackware64-current, Virtualbox 6.1.x testbuilds segfault

Post by fth0 »

AFAIR, the problem is not VirtualBox specific, although it occurs when starting the VirtualBox Manager. It has something to do with conflicting QT versions on the host, and you'll find similar reports when googling for "cannot register existing type".
slvr32
Posts: 13
Joined: 14. Feb 2019, 04:09

Re: Slackware64-current, Virtualbox 6.1.x testbuilds segfault

Post by slvr32 »

fth0 wrote:AFAIR, the problem is not VirtualBox specific, although it occurs when starting the VirtualBox Manager. It has something to do with conflicting QT versions on the host, and you'll find similar reports when googling for "cannot register existing type".
Or more specifically, Qt libraries with conflicting gtk2 vs gtk3 usage on the same host would likely be something to check for these days?

I noticed earlier that the VirtualBox packages shipped their own Qt libraries, renamed with VBox bits, e.g. libVBoxQtSomething.so, or something similar, to try to avoid library entanglements on a specific host, and maybe a little wrapper script to launch binaries, like (simplified)...

(cd /some/path/bin; export LD_LIBRARY_PATH=/some/path/lib; ./thebinary)

I'll see if I can check for signs of mixed library linking via ldd and/or nm, or take a look at some related <package>.SlackBuild scripts (how the packages were supposedly compiled upstream), to try to figure out any (likely gtk2/gtk3) conflicts with Qt libraries on the host.

Edit: never mind, I had built a patched wxWidgets-3.x.x from source to go with Audacity 3.0 last week, and recalled gtk2/gtk3 options, but I guess it's only styling, and Qt libraries have libglib linking, but no libgtk* linking, where I was thinking there might be gtk2/gtk3 conflicts.

It seems that trying to register an existing/duplicate type might be another reason for the error and segfault for NMAgentManagerError, but I'm not sure what to make of the last several calls of a gdb backtrace...

(process:18674): GLib-GObject-WARNING **: 22:51:46.139: cannot register existing type 'NMAgentManagerError'

(process:18674): GLib-CRITICAL **: 22:51:46.139: g_once_init_leave: assertion 'result != 0' failed

(process:18674): GLib-GObject-WARNING **: 22:51:46.139: cannot retrieve class for invalid (unclassed) type '<invalid>'

Thread 18 "UINetworkReplyP" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffc4d03640 (LWP 18724)]
0x00007fffe41bf0c2 in ?? () from /usr/lib64/libnm.so.0
(gdb) bt
#0 0x00007fffe41bf0c2 in () at /usr/lib64/libnm.so.0
#1 0x00007fffe41bf2d0 in () at /usr/lib64/libnm.so.0
#2 0x00007fffe418b237 in () at /usr/lib64/libnm.so.0
#3 0x00007ffff7fdd35e in call_init.part () at /lib64/ld-linux-x86-64.so.2
#4 0x00007ffff7fdd440 in _dl_init () at /lib64/ld-linux-x86-64.so.2
#5 0x00007ffff2ad5a1d in _dl_catch_exception () at /lib64/libc.so.6
Post Reply