FreeBSD 12.1-RELEASE-p2 amd64
After ports r528258 (bug #244603), VirtualBox memory faults on startup:
$ sh -x /usr/local/bin/VirtualBox
+ test -r /usr/local/etc/vbox/vbox.cfg
+ test -z ''
+ test -d /usr/local/lib/virtualbox
+ test -f /usr/local/lib/virtualbox/VBoxRT.so
+ export KDE_FORK_SLAVES
+ basename /usr/local/bin/VirtualBox
+ exec /usr/local/lib/virtualbox/VirtualBox
This is with virtualbox-ose installed from the "latest" pkg repo:
Mar 16 09:41:06 flake pkg: virtualbox-ose reinstalled: 5.2.34_1 -> 5.2.34_1
Created attachment 212543 [details]
truss -f virtualbox
At Kyle's request.
grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v
Fri 20 Mar 2020 07:10:47 GMT
FreeBSD 13.0-CURRENT #0 r359068: Wed Mar 18 21:14:12 GMT 2020 root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
grahamperrin@momh167-gjp4-8570p:~ % pkg query '%o %v %R' virtualbox-ose virtualbox-ose-kmod
emulators/virtualbox-ose 5.2.34_1 FreeBSD
emulators/virtualbox-ose-kmod 5.2.34 poudriere
It's caused by the usual conflict between libstdc++ and libc++ which
often cannot coexist in the same process. Building with GCC will
link everything with its libstdc++ while all the Qt5 libs are linked
with libc++ from base which breaks the Qt5 GUI. VBoxSDL (and
probably others that do not load libc++ too) still work fine like
(In reply to Tobias Kortkamp from comment #2)
I find it most curious that it works here locally and worked for madpilot@, but this explanation makes sense.
I'll go hunt down why clang miscompiles it.
Forgive an ignorant question: will building and installing locally work around the issue (for me)?
Depending on how long it may take to isolate and fix the issue, it may be prudent to revert the change for now so that the pkg repo has a working version in the interim.
(In reply to Greg Rivers from comment #5)
I intend to have a fix ready by the end of this weekend.
(In reply to Kyle Evans from comment #6)
Nice. Thank you very much for your work and service to the community.
(In reply to Kyle Evans from comment #3)
> I find it most curious that it works here locally and worked for madpilot@, but > this explanation makes sense.
I share the curiosity.
Maybe the difference is I'm running head?
I'm also upgrading my PCs at home, shortly I'll be in head with clang 10(which I guess brings a new libc++), maybe this will cause it to break again for me too?
*** Bug 245054 has been marked as a duplicate of this bug. ***
I'm confused (sorry) …
> … the head of the ports tree already has USE_GCC in it.
So I created a new jail, built and installed emulators/virtualbox-ose but still, there's a segmentation fault.