[vbox-dev] Bugs spotted when using VirtualBox 6.1.97 r140059.

[Cyrax]

On 28/08/2020 20:30, Klaus Espenlaub wrote:
> Hi,
> 
> On 2020-08-27 14:10, Cyrax wrote:
>> 1. Audio issues. When using PulseAudio driver in guets, VirtualBox
>> 6.1.97 r140059 creates several playback streams in the host OS and none
>> will output any sounds. Switching to ALSA driver, I get sound but
>> somehow changing other Guests volume affects other one.
> 
> I don't remember significant audio changes in quite a while. Are you
> sure that this is new in 6.1.97 (which is a dev version of what will be
> released in the unknown future) and does not happen in 6.1?
> 
> Also, you'd need to describe in a lot more detail what "using PulseAudio
> driver in guests" means. Which Linux distro, which audio config in the
> VM, all config details, VBox.log and so on. Otherwise we can't say much
> intelligent.
> 
> Or are you talking about using PulseAudio on the host (yeah, the driver
> is selected in the VM config, but it will not be used as such by the
> guest since that can be any OS)?

Host is Arch Linux with custom built kernel (for kdump functionality and 
ISA bus enabled for ISA soundcard (Sound Blaster 16) in the VirtualBox) 
5.7.18. One Guest is Windows Server 2008 R2 SP1 and other have Arch 
Linux (same custom built kernel as in the host) as its OS.

PulseAudio on the host (and in the Arch Linux guest) and "Host Audio 
Driver : PulseAudio" selected in the guest settings. Yes, that happens 
only 6.1.97 starting with r139689. 6.1.97 r139475 was working fine. And 
VirtualBox 6.1.13 r140124 (Qt5.6.1) is working fine, too.

>> 2. Taking a snapshot aborts running guest. This happened to Windows
>> Guest of mine. Attached two files which one is output from "coredumpctl
>> info" and the log file of the guest (VBox.log)
> 
> This could be anything... from the stack traces it's some sort of heap
> corruption (from the looks detected straight after a new thread was
> started). Not something we're seeing ourselves so far.
> 
> VBox.log is always useful (even though if this case it doesn't
> correspond to the crash you mentioned, because it's a successful VM run
> which takes about 14 seconds, ending with a poweroff). It shows that
> you're using a rather unsuspecting VM config.
> 
> Klaus
> 

Hmm, alright.