Crash on boot when changing IP address range

[prion]

Hello there,

I noticed a strange bug causing a serious crash on VirtualBox 5.2.18 for Mac. The bug happens when changing the default NAT address pool, and specifically when setting the subnet mask to a number greater than 24.

I don't know if this behavior is undefined and thus normal, I just wanted to report it if not. To reproduce it, I created a virtual machine using these commands :

Code: Select all

VBoxManage createvm --name "debian-vm" --ostype debian-vm_64 --register
VBoxManage modifyvm "debian-vm" --memory 4096
VBoxManage modifyvm "debian-vm" --vram 256
VBoxManage storagectl "debian-vm" --name "SATA Controller" --add sata --controller IntelAhci
VBoxManage storageattach "debian-vm" --storagectl "SATA Controller" --port 0 --device 0 --type hdd --medium "/Users/emandret/VDI/debian-vm.vdi"
VBoxManage modifyvm "debian-vm" --nic1 nat
VBoxManage modifyvm "debian-vm" --natnet1 "192.168.0.0/24"

Notice how I changed the address range pool on the last line. Changing the mask from 24 to 30, for instance, would wreak havoc and cause an immediate crash when booting up.

Here is the report from my operating system (MacOS Sierra) :

Crashed Thread:        16  EMT

Exception Type:        EXC_BREAKPOINT (SIGTRAP)
Exception Codes:       0x0000000000000002, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Trace/BPT trap: 5
Termination Reason:    Namespace SIGNAL, Code 0x5
Terminating Process:   exc handler [0]

Application Specific Information:
*** CFHash() called with NULL ***

Thank you in advance for your answers.

[prion]

UP

[socratis]

I'm keeping your post in an open tab in my browser in order to notify the developers come Monday. Other than that, what are you actually expecting from a user forum? A solution to a potential bug?

And please don't bump a thread in a weekend less than 24 hours...

Patience you must learn my young Padawan...

• Yoda

[vushakov]

Yes, NAT doesn't really support long prefixes for historical reasons. When the ability to specify the address/mask was added it was not properly restricted. You can get away with up to /27 but only if you use the first subnet. We will restrict the ability to set the address/mask to values that actually work.

[vushakov]

Actually, this turned out to be osx-specific problem. It was actually trying to tell you the netmask is bad, but there was a bug in cleanup code. Thanks for the report.

[socratis]

It was actually trying to tell you the netmask is bad

Oh, it did that alright... it really did that!

causing a serious crash