I'm getting the following error when trying to create a new virtual machine. The exact moment I get this error message is when I click "Create" in the "Hard disk" dialog during the creation process of a new machine. The VirtualBox application does not crash: it just does not allow me to create a new machine. Existing machines seem to work fine. > Failed to create a new virtual machine. > > Unexpected exception: cxxrt::bad_alloc [St9bad_alloc] > > /wrkdirs/usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.26/out/freebsd.amd64/release/obj/VBoxAPIWrap/VirtualBoxWrap.cpp[1323] (virtual nsresult VirtualBoxWrap::CreateMachine(CBSTR, CBSTR, PRUint32, CBSTR *, CBSTR, CBSTR, IMachine **)). > > Result Code: NS_ERROR_FAILURE (0x80004005) > Component: VirtualBoxWrap > Interface: IVirtualBox {9570b9d5-f1a1-448a-10c5-e12f5285adad} I'm running FreeBSD 13.0-CURRENT r345136 GENERIC amd64 with virtualbox-ose-5.2.26_3. Let me know if I can
Let me know if I can provide any help with debugging.
Here are some additional error messages I get when running "vagrant up" to create a new machine: > There was an error while executing `VBoxManage`, a CLI used by Vagrant > for controlling VirtualBox. The command and stderr is shown below. > > Command: ["import", "-n", "/home/0mp/.vagrant.d/boxes/ubuntu-VAGRANTSLASH-bionic64/20190219.0.0/virtualbox/box.ovf"] > > Stderr: 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% > Interpreting /home/0mp/.vagrant.d/boxes/ubuntu-VAGRANTSLASH-bionic64/20190219.0.0/virtualbox/box.ovf... > OK. > VBoxManage: error: Output argument aExtraConfigValues points to invalid memory location (0000000000000000) > VBoxManage: error: Details: code NS_ERROR_INVALID_POINTER (0x80004003), component VirtualSystemDescriptionWrap, interface IVirtualSystemDescription, callee nsISupports > VBoxManage: error: Context: "GetDescription(ComSafeArrayAsOutParam(retTypes), ComSafeArrayAsOutParam(aRefs), ComSafeArrayAsOutParam(aOvfValues), ComSafeArrayAsOutParam(aVBoxValues), ComSafeArrayAsOutParam(aExtraConfigValues))" at line 387 of file VBoxManageAppliance.cpp Tested on FreeBSD 13.0-CURRENT r345294 GENERIC amd64, vagrant-2.2.4_1, virtualbox-ose-5.2.26_3.
> Unexpected exception: cxxrt::bad_alloc [St9bad_alloc] I have got the same error. Building with clang70 from ports fixed it for me.
(In reply to Vladimir Kondratyev from comment #3) Confirmed, building with clang70 from ports fixed it for me as well.
(In reply to Mateusz Piotrowski from comment #1) > Let me know if I can provide any help with debugging. Can you try to get a stack trace for the exception? E.g. by running the thing in gdb, and using "catch throw" to catch the exception first-chance, and when it is hit, run "bt".
(In reply to Dimitry Andric from comment #5) Well, VirtualBox is not crashing on my machine. Those are the virtual machines inside VirtualBox that are affected.
(In reply to Mateusz Piotrowski from comment #2) > Here are some additional error messages I get when running "vagrant up" to > create a new machine: > > > There was an error while executing `VBoxManage`, a CLI used by Vagrant > > for controlling VirtualBox. The command and stderr is shown below. > > > > Command: ["import", "-n", "/home/0mp/.vagrant.d/boxes/ubuntu-VAGRANTSLASH-bionic64/20190219.0.0/virtualbox/box.ovf"] > > > > Stderr: 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% > > Interpreting /home/0mp/.vagrant.d/boxes/ubuntu-VAGRANTSLASH-bionic64/20190219.0.0/virtualbox/box.ovf... > > OK. > > VBoxManage: error: Output argument aExtraConfigValues points to invalid memory location (0000000000000000) > > VBoxManage: error: Details: code NS_ERROR_INVALID_POINTER (0x80004003), component VirtualSystemDescriptionWrap, interface IVirtualSystemDescription, callee nsISupports > > VBoxManage: error: Context: "GetDescription(ComSafeArrayAsOutParam(retTypes), ComSafeArrayAsOutParam(aRefs), ComSafeArrayAsOutParam(aOvfValues), ComSafeArrayAsOutParam(aVBoxValues), ComSafeArrayAsOutParam(aExtraConfigValues))" at line 387 of file VBoxManageAppliance.cpp > > Tested on FreeBSD 13.0-CURRENT r345294 GENERIC amd64, vagrant-2.2.4_1, > virtualbox-ose-5.2.26_3. I can reproduce these, but I have no clue what causes it. The code is hard to follow due to all the macros and object interfacing... It doesn't throw here, at least, so I don't see any bad_alloc exceptions.
Hi, I'm seeing this too, but with a strange twist. I have a laptop and a desktop machine both running the same FreeBSD version (13 r345473 at present), I'm using packaged base and both machines use the exact same package set, for both base and ports. Virtualbox was working fine on both, I am now reinstalling the desktop machine from scratch. Virtualbox keeps working fine on the laptop, also being able to create new VMs. On the reinstalled desktop machine instead, launching it from scratch (no configuration here) it fails with the reported error when trying to create a new VM. This is really strange IMHO, since the two machines are running the exact same binaries. Could be configuration related, or caused by some dependency? I'm now going to force the rebuild of the virtualbox packages, just in case. After this I could force virtualbox to be rebuilt using clang 6 or clang 7.
For further information, recovering the old .VirtualBox directory reproduced the old setup, and I'm able to launch and use normally the old VMs, but if I try to create a new one the error persists.
I'd also like to confirm that compiling virtualbox with clang/llvm 7.0 makes it work again.
Created attachment 203549 [details] Use type_traits to unbreak runtime issues Can you please try this patch *with* Clang 8, i.e., default compiler?
(In reply to Jung-uk Kim from comment #11) > Created attachment 203549 [details] > Use type_traits to unbreak runtime issues > > Can you please try this patch *with* Clang 8, i.e., default compiler? I recompiled applying your patch using the default clang 8 (the system compiler) but I get the same error when trying to create a new VM.
(In reply to Guido Falsi from comment #12) > (In reply to Jung-uk Kim from comment #11) > > Created attachment 203549 [details] > > Use type_traits to unbreak runtime issues > > > > Can you please try this patch *with* Clang 8, i.e., default compiler? > > I recompiled applying your patch using the default clang 8 (the system > compiler) but I get the same error when trying to create a new VM. Actually now that I'm running with this patched version I'm seeing VMs crashing after some time they run. Not sure if this is caused by the patch. I'll report back if reverting to virtualbox compiled with clang 7.0 makes the crashes disappear.
A commit references this bug: Author: jkim Date: Wed Apr 10 20:47:24 UTC 2019 New revision: 498595 URL: https://svnweb.freebsd.org/changeset/ports/498595 Log: Apply a bandaid to work around runtime issues with Clang 8.0. PR: 236616 Changes: head/emulators/virtualbox-ose/Makefile
(In reply to Guido Falsi from comment #13) Okay, sorry for the noise. It will take some time to figure out what's really going on here. For now, we're falling back to devel/llvm60 on head.
(In reply to Jung-uk Kim from comment #15) > (In reply to Guido Falsi from comment #13) > Okay, sorry for the noise. It will take some time to figure out what's > really going on here. For now, we're falling back to devel/llvm60 on head. Nothing to be sorry about. Thanks for trying to fix it!
(In reply to commit-hook from comment #14) This change does help. Thanks.
if I understand right, it seems fixed. Can we close here?
(In reply to Walter Schwarzenfeld from comment #18) > if I understand right, it seems fixed. Can we close here? IMHO yes, the problem is solved now that the port uses clang/llvm 6.0 I'm not sure what can be done for using a newer compiler.
Re-opening... pinning virtualbox to an old compiler isn't really a sustainable solution, unfortunately, as that potentially (as in, right now) holds back real improvements to base that require newer compilers. We really need to work out why the newer versions aren't working or force it over to GCC until we can do so, if that's feasible.
Due to being pinned to olgd clang virtualbox is now failing to build on head after r358439 As a workaround I've added this to make.conf in poudriere: .if ${.CURDIR:M*emulators/virtualbox-ose} USE_GCC=9 .endif and so building virtualbox with recent gcc. It works fine for me.
(In reply to Guido Falsi from comment #21) This path, yes? /usr/local/etc/poudriere.d/make.conf
(In reply to Graham Perrin from comment #22) > This path, yes? > > /usr/local/etc/poudriere.d/make.conf for poudriere yes, or a more specific one if you want it to apply only to certain builds, anyway it is not necessary anymore, the head of the ports tree already has USE_GCC in it.
No go for me with 5.2.34_1 ---- grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v Mon 23 Mar 2020 15:44:28 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:~ % virtualbox Segmentation fault grahamperrin@momh167-gjp4-8570p:~ % pkg query '%o %v %R' virtualbox-ose virtualbox-ose-kmod emulators/virtualbox-ose 5.2.34_1 poudriere emulators/virtualbox-ose-kmod 5.2.34 poudriere grahamperrin@momh167-gjp4-8570p:~ % ---- Do I shoot myself in the foot with one of the three lines below? root@momh167-gjp4-8570p:~ # grep -v \# /usr/local/etc/poudriere.d/make.conf WITHOUT_LLVM_TARGET_ALL= MESA_LLVM_VER=${LLVM_DEFAULT} DEFAULT_VERSIONS+=llvm=10 ---- Incidentally I see 5.2.34_1 for two commits, the first of which was in February, at <https://www.freshports.org/emulators/virtualbox-ose/>
Sorry, disoriented. My previous comment (segmentation fault) probably belonged under bug 244847
A commit references this bug: Author: kevans Date: Tue Apr 14 13:47:52 UTC 2020 New revision: 531689 URL: https://svnweb.freebsd.org/changeset/ports/531689 Log: emulators/virtualbox-ose: Switch build to USES= compiler:c++14-lang The runtime breakage that started occurring after the LLVM 7 -> 8 transition has been diagnosed with help from cem@, and the attached patch fixes it. The problem ended up being that tail-call optimization was being applied to this function (which should probably be written in assembly instead) and moving the tail-call to later on after some stack manipulations. The problem with this is that this particular function uses alloca() to carefully craft a stack that it's expecting to be used for the function it's calling at the end. The new patch fixes this using a technique that was committed later on in upstream changeset 75061 to address a similar failure with GCC sanitizers enabled. The FreeBSD-specific component of this patch is using the different stack setup if __clang__ is defined as well. The extra hunk in the Config patch has been added because the VirtualBox build system cannot cope with LLVM version numbers in the way it's expecting. Hardcode it to GCC 4.2 for FreeBSD, which is what the clang __GNU* macros describe, to fix build breakage that happens with newer LLVM as the build system decides our LLVM is an even older and more broken version of GCC with a broken regparm. PR: 236616, 244847 Approved by: koobs (mentor) MFH: 2020Q2 (blanket: major runtime build fix) Changes: head/emulators/virtualbox-ose/Makefile head/emulators/virtualbox-ose/files/patch-Config.kmk head/emulators/virtualbox-ose/files/patch-src_libs_xpcom18a4_xpcom_reflect_xptcall_src_md_unix_xptcinvoke__x86__64__linux.cpp
A commit references this bug: Author: kevans Date: Tue Apr 14 13:51:05 UTC 2020 New revision: 531690 URL: https://svnweb.freebsd.org/changeset/ports/531690 Log: MFH: r531689 emulators/virtualbox-ose: Switch build to USES= compiler:c++14-lang The runtime breakage that started occurring after the LLVM 7 -> 8 transition has been diagnosed with help from cem@, and the attached patch fixes it. The problem ended up being that tail-call optimization was being applied to this function (which should probably be written in assembly instead) and moving the tail-call to later on after some stack manipulations. The problem with this is that this particular function uses alloca() to carefully craft a stack that it's expecting to be used for the function it's calling at the end. The new patch fixes this using a technique that was committed later on in upstream changeset 75061 to address a similar failure with GCC sanitizers enabled. The FreeBSD-specific component of this patch is using the different stack setup if __clang__ is defined as well. The extra hunk in the Config patch has been added because the VirtualBox build system cannot cope with LLVM version numbers in the way it's expecting. Hardcode it to GCC 4.2 for FreeBSD, which is what the clang __GNU* macros describe, to fix build breakage that happens with newer LLVM as the build system decides our LLVM is an even older and more broken version of GCC with a broken regparm. PR: 236616, 244847 Approved by: koobs (mentor) Approved by: ports-secteam (blanket: major runtime fix caused by bad build) Changes: _U branches/2020Q2/ branches/2020Q2/emulators/virtualbox-ose/Makefile branches/2020Q2/emulators/virtualbox-ose/files/patch-Config.kmk branches/2020Q2/emulators/virtualbox-ose/files/patch-src_libs_xpcom18a4_xpcom_reflect_xptcall_src_md_unix_xptcinvoke__x86__64__linux.cpp
Build has been switched back to llvm with a fix for the part that regressed between LLVM 7 and 8. Closing this because, as far as I'm aware, this should no longer be any kind of issue.
A commit references this bug: Author: cy Date: Wed Apr 15 02:29:04 UTC 2020 New revision: 531736 URL: https://svnweb.freebsd.org/changeset/ports/531736 Log: Fix r531689 i386 build. PR: 236616, 244847 Submitted by: kevans MFH: 2020Q2 (blanket: major runtime build fix) MFH-with: r531689 Changes: head/emulators/virtualbox-ose/Makefile head/emulators/virtualbox-ose/files/patch-src_VBox_VMM_include_IEMInternal.h
A commit references this bug: Author: kevans Date: Thu Apr 16 00:19:35 UTC 2020 New revision: 531801 URL: https://svnweb.freebsd.org/changeset/ports/531801 Log: MFH: r531736 Fix r531689 i386 build. PR: 236616, 244847 Submitted by: kevans MFH-with: r531689 Approved by: ports-secteam (blanket: i386 build fix) Changes: _U branches/2020Q2/ branches/2020Q2/emulators/virtualbox-ose/Makefile branches/2020Q2/emulators/virtualbox-ose/files/patch-src_VBox_VMM_include_IEMInternal.h