Bug 236616 - emulators/virtualbox-ose: Unable to create a new machine due to "Unexpected exception: cxxrt::bad_alloc [St9bad_alloc]"
Summary: emulators/virtualbox-ose: Unable to create a new machine due to "Unexpected e...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: vbox (Nobody)
URL:
Keywords: regression
Depends on: 244603
Blocks: 244847
  Show dependency treegraph
 
Reported: 2019-03-18 11:41 UTC by Mateusz Piotrowski
Modified: 2020-04-16 00:20 UTC (History)
10 users (show)

See Also:
bugzilla: maintainer-feedback? (vbox)


Attachments
Use type_traits to unbreak runtime issues (2.44 KB, patch)
2019-04-10 01:19 UTC, Jung-uk Kim
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mateusz Piotrowski freebsd_committer 2019-03-18 11:41:49 UTC
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
Comment 1 Mateusz Piotrowski freebsd_committer 2019-03-18 11:42:22 UTC
Let me know if I can provide any help with debugging.
Comment 2 Mateusz Piotrowski freebsd_committer 2019-03-20 09:58:27 UTC
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.
Comment 3 Vladimir Kondratyev freebsd_committer 2019-03-30 00:38:19 UTC
> Unexpected exception: cxxrt::bad_alloc [St9bad_alloc]

I have got the same error.

Building with clang70 from ports fixed it for me.
Comment 4 Steve Wills freebsd_committer 2019-04-01 17:36:45 UTC
(In reply to Vladimir Kondratyev from comment #3)
Confirmed, building with clang70 from ports fixed it for me as well.
Comment 5 Dimitry Andric freebsd_committer 2019-04-01 17:56:00 UTC
(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".
Comment 6 Mateusz Piotrowski freebsd_committer 2019-04-02 10:45:59 UTC
(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.
Comment 7 Dimitry Andric freebsd_committer 2019-04-02 19:21:11 UTC
(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.
Comment 8 Guido Falsi freebsd_committer 2019-04-07 08:56:14 UTC
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.
Comment 9 Guido Falsi freebsd_committer 2019-04-07 09:24:14 UTC
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.
Comment 10 Guido Falsi freebsd_committer 2019-04-07 16:16:36 UTC
I'd also like to confirm that compiling virtualbox with clang/llvm 7.0 makes it work again.
Comment 11 Jung-uk Kim freebsd_committer 2019-04-10 01:19:49 UTC
Created attachment 203549 [details]
Use type_traits to unbreak runtime issues

Can you please try this patch *with* Clang 8, i.e., default compiler?
Comment 12 Guido Falsi freebsd_committer 2019-04-10 17:20:09 UTC
(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.
Comment 13 Guido Falsi freebsd_committer 2019-04-10 19:17:15 UTC
(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.
Comment 14 commit-hook freebsd_committer 2019-04-10 20:47:51 UTC
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
Comment 15 Jung-uk Kim freebsd_committer 2019-04-10 20:50:21 UTC
(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.
Comment 16 Guido Falsi freebsd_committer 2019-04-10 21:07:07 UTC
(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!
Comment 17 Mateusz Piotrowski freebsd_committer 2019-04-11 12:27:14 UTC
(In reply to commit-hook from comment #14)

This change does help. Thanks.
Comment 18 Walter Schwarzenfeld freebsd_triage 2019-08-29 16:59:35 UTC
if I understand right, it seems fixed. Can we close here?
Comment 19 Guido Falsi freebsd_committer 2019-09-02 08:24:17 UTC
(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.
Comment 20 Kyle Evans freebsd_committer 2020-03-03 02:13:38 UTC
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.
Comment 21 Guido Falsi freebsd_committer 2020-03-04 17:40:04 UTC
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.
Comment 22 Graham Perrin 2020-03-23 02:46:40 UTC
(In reply to Guido Falsi from comment #21)

This path, yes? 

/usr/local/etc/poudriere.d/make.conf
Comment 23 Guido Falsi freebsd_committer 2020-03-23 08:51:34 UTC
(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.
Comment 24 Graham Perrin 2020-03-23 16:53:20 UTC
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/>
Comment 25 Graham Perrin 2020-03-23 18:08:03 UTC
Sorry, disoriented. My previous comment (segmentation fault) probably belonged under bug 244847
Comment 26 commit-hook freebsd_committer 2020-04-14 13:48:35 UTC
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
Comment 27 commit-hook freebsd_committer 2020-04-14 13:51:41 UTC
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
Comment 28 Kyle Evans freebsd_committer 2020-04-14 13:53:55 UTC
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.
Comment 29 commit-hook freebsd_committer 2020-04-15 02:29:26 UTC
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
Comment 30 commit-hook freebsd_committer 2020-04-16 00:20:23 UTC
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