VirtualBox Updates

Topic

New Reply

VirtualBox 7.1.6 / 7.0.24 This is a maintenance release.

https://www.virtualbox.org/wiki/Downloads

Release notes

VirtualBox 7.0.24

3 users thanked author for this post.

Speccy, bowled845, nevelsmf3

Reply | Quote

Replies

This latest release has a few oddities that shed a light on Oracle’s QA, providing clues to people that have been complaining that it seems like each new version is getting worse than the previous one and scratching their heads on why some “persistent” bugs and “weird” issues never seem to be properly fixed.

Puzzled on why the new 7.0.24 Windows setup doubled (!) its size, compared to the previous 7.0.22 version – especially since both setups seem to unpack similar contents (191 files with approximately 212Mb)

I took a closer look and pinpointed that the main size difference between the two binaries boils down to the ‘BIN_00’ RC Data resource at the .rsrc section (Initialized Data):

It turns out that the new 7.0.24 version has some “Easter eggs”: a lot of additional, unexpected contents were added and embedded into the final setup – probably by mistake, likely due to some “AI/automation bs involved in the building process“…

We’re talking here about pieces of information that are not present in previous versions of the setup (they’re probably not needed or ever used by the setup, at all) but do appear to be part of a Continuous Integration/Continuous Delivery/Deployment (CI/CD) pipe lined environment used by Oracle teams to compile and build the final setup – including, but not limited to, shell scripts (debian_postinstall.sh – A post installation script template for debian-like distros), Python scripts (vboxapi.py – VirtualBox Python API Glue), C language headers, .rtf license files (COPYING), WSDL definitions (src/VBox/Main/webservice/websrv-wsdl.xsl Generator, Generated from: src/VBox/Main/idl/VirtualBox.xidl (VirtualBox’s interface definitions in XML)) and other binary contents.

What bugs me most is not the reason why these contents ended up being part of the setup in the first place (someone messed up, period – it sucks, but it happens). What worries me, as a user is that some of these contents appear to be partially <span style=”text-decoration: underline;”>CORRUPTED</span> by seemingly random pieces of “garbage” (extraneous UNICODE characters):

Being optimistic here, perhaps the original resources are not corrupted (only these “useless” copies that were embedded by mistake into the setup). However, from a user’s perspective, this doesn’t look good and (sadly and a bit unfairly, given the product’s past history) it’s a red flag that might serve as an eye-opener to how software is being “built” these days and, unfortunately, casts a shadow over the quality of the product and the confidence users should have about using it.

Just my 2 cents,

2 users thanked author for this post.

dg1261, nevelsmf3

Reply | Quote

And why all of a sudden this depency?

 

 

Reply | Quote

There doesn’t seem to be a new dependency all of a sudden: that Python Core package dependency your screenshot refers to exists in previous versions, too, if you select the ‘VirtualBox Python support’ item (which I normally DON’T).

The extraneous contents I wrote about are unrelated to that.

It seems like someone might have mistakenly chosen the wrong flags when triggering the usual build process, causing the final setup to embed more than what it should: some parts of the build environment itself (of which we usually have no visibility at all).

In previous versions, these were not part of the product itself, neither were part of the setup installer. Under normal conditions, the final setup would not have to “inherit” and embed (or use) those extra contents, at all. That assumption is reinforced by the fact that the main contents of the new setup (those 191 files I mentioned in the post) appear to be (only) the exact same, updated equivalents of the previous version.

Whatever happened, the final setup ended up being (unnecessarily?) larger than it should because it also embedded those extra (useless and unused?) contents “inherited” from the build environment. My point was more about noticing that many of these contents seemed to be partially CORRUPTED.

On the other hand, that might not be true or a big deal at all, IF those contents are NOT exact copies of the original contents. The compiler might have simply decided to use and embed into the final setup whatever was in memory at compile time (to put it simply, memory is constantly reused and overwritten: that’s why many programming languages require variables to be declared and initialized – rather than assuming they will always have a predefined well-known value – so they won’t get “garbage” values from the stack or unexpected, random memory addresses).

It MAY be a problem, though, if those extra contents are, indeed, exact copies of the original resources (in that build environment). It MAY be a problem if those extra contents do reflect some sort of file CORRUPTION that might have been going on, unnoticed, in the build environment that might be the root cause of weird “bugs” and issues that affect normal features and prevent them from working correctly, as expected.

We simply don’t know. And that’s why I wrote it might be a red flag. If that is the case – and some parts of Oracle’s build environment are not pristine as they should but, instead, they do include partially corrupted files – then IMHO the VB team engineers should take a look at what’s going on and fix those issues before they escalate into deeper, more complex problems.

Again, being optimistic here, eventually they’ll notice something’s not right and will fix things up in the next release. Let’s hope so. In the meantime, VB users using v7.0.22 might be better off skipping v7.0.24 at all and just waiting a little bit more for the next, upcoming v7.0.26 version to be released.

Just my 2 cents,

1 user thanked author for this post.

nevelsmf3

Reply | Quote

[Speccy]

Just a quick update, as it seems there’s indeed what it seems to be a logic explanation and a confirmation that the observed random artifacts do not mean corrupted contents but are, instead, rather normal since they’re related with compression.

https://forums.virtualbox.org/viewtopic.php?p=554048#p554048

Quoting:

“The reason [why the Windows installer has nearly doubled in size from 106MB for 7.0.22 to 216MB for 7.0.24] is that the compression settings were in a way ‘lost’ during a larger installer rework. Purely affects the download size, doesn’t mean that there’s much more code or some such. As soon as we have a new test build next week it’ll be back to the usual size.”

This seems to confirm that v7.0.24 is OK (good to know) and the upcoming 7.0.x setup version (probably v7.0.26) is expected to be released, again, with the usual, “normal” size.

• This reply was modified 2 months, 1 week ago by Speccy. Reason: fixing mispelled word ('lost' incorrectly mispelled as 'list')

Reply | Quote