segfault on arch linux due to missing libdl.so => fixed in SVN

[thorstenhirsch]

There's a thread in the arch forum with lots of details, see: ​https://bbs.archlinux.org/viewtopic.php?id=299392

Summary: VirtualBox 7.1.x seems to be linked (transitively?) against libdl.so, which is missing on modern Linux installations. As a workaround users can create the following symlink:

/usr/lib/virtualbox/libdl.so -> /usr/lib/libdl.so.2

But the real solution would be that Oracle fixes the build.

P.S.: Not sure about the necessity of a similar libpthread.so symlink, which is also mentioned in the linked thread.

[Trevor Hemsley]

Also broken on Fedora 40 and fixed by running

cd /usr/lib64/virtualbox
ln -s ../libpthread.so.0 libpthread.so
ln -s ../libdl.so.2 libdl.so

Tried with just the libdl.so symlink first but still failed until the libpthread one was created too.

[thorstenhirsch]

Problem stays the same in VirtualBox 7.1.4

[galitsyn]

Hi thorstenhirsch,

Do you see this issue with the official build from Downloads page? We don't ship package for Arch Linux (you could try "All distributions" .run version though), but with Fedora package I do not see the problem you are reporting.

If VirtualBox package is built by your distribution, please consider filing a report to Arch bug tracker.

[mmmmmmmax]

Same issue with Debian 12. I get the segfault until I add the symlinks from comment 1. (Then I get another error related to the kernel module, but that's a different issue.)

I suggest that the issue title is changed to show that the problem is not only on Arch.

[galitsyn]

Hi mmmmmmmax,

Which package have you installed?

[davedeaven]

This also occurs on OpenSuSE LEAP 15.6, virtualbox 7.1.4-lp156.2.4.1 and is resolved by adding explicit symlinks in /usr/lib/virtualbox:

/usr/lib/virtualbox/libdl.so -> /lib64/libdl.so.2
/usr/lib/virtualbox/libpthread.so -> /lib64/libpthread.so.0

[bq]

I also have the same problem on Ubuntu 22.04.5 and VB 7.1.4 installed from the VB Repo from https://www.215389.xyz/wiki/Linux_Downloads. All patches up to date. Slightly different paths required:

/usr/lib/virtualbox/libpthread.so -> /usr/lib/x86_64-linux-gnu/libpthread.so.0
/usr/lib/virtualbox/libdl.so -> /usr/lib/x86_64-linux-gnu/libdl.so.2

libpthread link is required for me.

[sideral]

As this seems to be an issue that's only exposed by distro packages, I have created a downstream bug report for openSUSE here: ​https://bugzilla.suse.com/show_bug.cgi?id=1240833.

[galitsyn]

Replying to bq:

I also have the same problem on Ubuntu 22.04.5 and VB 7.1.4 installed from the VB Repo from https://www.215389.xyz/wiki/Linux_Downloads. All patches up to date. Slightly different paths required:

/usr/lib/virtualbox/libpthread.so -> /usr/lib/x86_64-linux-gnu/libpthread.so.0
/usr/lib/virtualbox/libdl.so -> /usr/lib/x86_64-linux-gnu/libdl.so.2

libpthread link is required for me.

Have you install .run package from downloads page or .deb one? Also, could you please attach a backtrace of crashing process?

[sideral]

Replying to myself in an earlier comment:

As this seems to be an issue that's only exposed by distro packages, I have created a downstream bug report for openSUSE here: ​https://bugzilla.suse.com/show_bug.cgi?id=1240833.

The openSUSE maintainer marked my bug report as a duplicate of ​another report, which contained a crucial clue: The symbolic-link workaround is not needed for fresh VirtualBox configurations, but only for configurations inherited from an older version of VirtualBox.

This insight prompted me to look for references to the suspicious dynamic libraries in my VirtualBox configuration. And I found this:

~/.config/VirtualBox> grep libdl *
compreg.dat:rel:VBoxXPCOMIPCC.so,1182466622000,VBoxXPCOM.so libpthread.so libdl.so

Looks like compreg.dat is caching some dynamic loader configuration.

Removing this file resolved the issue for me.

[bird]

The problem *seems* to affect really long time users of VBox where compreg.dat contains an outdated entry for the VBoxXPCOMIPCC.so component (above example is dated 2007-06-22). For various reasons, the entry for that component wasn't ever updated as new versions of VBox shipped. So, when we disabled the bogus generating of dependencies (VBoxXPCOM.so libpthread.so libdl.so) in 2008, the list for the VBoxXPCOMIPCC.so entry was carried along. Hard to believe that some of these files have stayed around for 17+ years. :)

Anyway, the issue is fixed in SVN and backported to 7.1. Test builds with revision r168606 or later should include the fix.

Just deleting the compreg.dat file will fix the issue as well. It will automatically be re-generated, so this is perfectly safe.