When bhyve is run using: bhyveload -d test.img -m <anything> test bhyve -A -H -P -s 0:0,hostbridge -s 1:0,lpc -s 2:0,virtio-blk,./test.img -l com1,stdio -c <any> -m <anything> -t test the "bhyve" process aborts with an assertion: Assertion failed: (error == 0), function main, file /home/dstolfa/freebsd-head/usr.sbin/bhyve/bhyverun.c, line 1096. I have traced the error to the vfprintf in dsdt_line() inside acpi.c, however I have not been able to use gdb from ports or lldb to debug this effectively due to various freezes that I've experienced (not gaining control back in the debugger or failing to execute the child in lldb's case). Adding a number of printfs, namely printf("%s\n", bf->f_name); when creating the temporary files removes the bug, but so does adding printfs when the VM shuts down which leads me to believe that this is in fact a code segment corruption rather than a race.
(In reply to Domagoj Stolfa from comment #0) The -t snuck in there by accident (typo). Ignore that bit, the invocation is: bhyve -A -H -P -s 0:0,hostbridge -s 1:0,lpc -s 2:0,virtio-blk,./test.img -l com1,stdio -c <any> -m <anything> test
Domagoj - which version/SVN change # of FreeBSD is on the host system ?
(In reply to Peter Grehan from comment #2) Hi Peter: The revision this was tested on was r332573. Thanks!
(In reply to Domagoj Stolfa from comment #3) Thinking about this more, it is possible that this is a side-effect of a race in NFS (as this system is booted over NFS). It's possible that mkstemp(s)() gets called and gets a file descriptor, but the file is not actually there by the time we try and write it? One difficulty with this though is that it happens consistently only on DSDT and never on anything else -- but this information might help when trying to reproduce the issue. Mind you, this is all UFS.