v2.4.1 crashes on start with old settings file (out-of-range `<stretch>` value)

I haven't played VVVVVV in years, but I figured I'd start it up again with the new update. Unfortunately, when I did so, I was met with

$ ./build/VVVVVV
[INFO] Base directory: /home/thebb/.local/share/VVVVVV/
[INFO] Save directory: /home/thebb/.local/share/VVVVVV/saves/
[INFO] Level directory: /home/thebb/.local/share/VVVVVV/levels/
[INFO] Screenshot directory: /home/thebb/.local/share/VVVVVV/screenshots/
[WARN] Cannot find the lang directory anywhere!
[INFO] Languages directory:
[WARN] Cannot find the fonts directory anywhere!
[INFO] gamecontrollerdb.txt not found!
[INFO] 		
[INFO] 		
[INFO] 		       VVVVVV
[INFO] 		
[INFO] 		
[INFO] 		  8888888888888888
[INFO] 		88888888888888888888
[INFO] 		888888    8888    88
[INFO] 		888888    8888    88
[INFO] 		88888888888888888888
[INFO] 		88888888888888888888
[INFO] 		888888            88
[INFO] 		88888888        8888
[INFO] 		  8888888888888888
[INFO] 		      88888888
[INFO] 		  8888888888888888
[INFO] 		88888888888888888888
[INFO] 		88888888888888888888
[INFO] 		88888888888888888888
[INFO] 		8888  88888888  8888
[INFO] 		8888  88888888  8888
[INFO] 		    888888888888
[INFO] 		    8888    8888
[INFO] 		  888888    888888
[INFO] 		  888888    888888
[INFO] 		  888888    888888
[INFO] 		
[INFO] 		
[INFO] qsave.vvv not found
[INFO] tsave.vvv not found
[INFO] No settings.vvv found. Creating new file
[INFO] Loading font "font"...
[INFO] Loading music from PPPPPP blob...
zsh: floating point exception (core dumped)  ./build/VVVVVV

A bit of (easy, thanks to the unstripped binary!) digging revealed that these lines were dividing by zero:

VVVVVV/desktop_version/src/KeyPoll.cpp

Lines 554 to 555 in 91e1447

    
           mousex = (raw_mousex - rect.x) * SCREEN_WIDTH_PIXELS / rect.w; 
        
           mousey = (raw_mousey - rect.y) * SCREEN_HEIGHT_PIXELS / rect.h;

The divisions were added in commit 77a5710 (from #1140), and indeed a bisect showed that the game started up fine prior to that commit. However, the root cause turned out not to be those lines, but rather the new switch statement used to set scaling parameters. It expects gameScreen.scalingMode, which is read from <stretch> in unlock.vvv/settings.vvv, to be either 0, 1, or 2.

But in my unlock.vvv, which is dated June 12th, 2014, <stretch> is 37! As a result, get_stretch_info() never populates any values of the passed SDL_Rect, which breaks both the division above and rendering in general. Here's the exact settings file that I had:

unlock_vvv.txt

I tested on Arch Linux, SDL 2.30.0, Sway Git, with both the Wayland and X11 SDL drivers.

cc @AllyTally, who wrote #1140

Out of curiosity, do you know how you might have gotten your save file into that state? You have a couple more interesting values in there:

        <stretch>37</stretch>
        <useLinearFilter>160</useLinearFilter>
        <usingmmmmmm>32767</usingmmmmmm>

To me it seems like either this was some kind of bug with uninitialized data being saved in certain conditions, or you were fuzzing the game (and were unexpectedly successful, 10 years later!)

I don't believe I ever edited that file manually, and I certainly never tried to fuzz the game. I played it briefly back then, and this file was the result. I don't know exactly what version produced it, but it'd have either been a Steam or the Humble Bundle distribution from that time.

The values aren't totally bogus, since the width and height (1440x900) match the monitor I had at the time.

VVVVVV 2.2 was originally released precisely the day before your save file (11 June 2014).

Reading back threads from back then, there were definitely some teething issues in the first few days; including random crashes while playing and unrelated problems with save folders, that got patched out within days after release. I don't think 2.2's version history was ever properly tracked, but there were definitely several updates made in the first week. It seems very possible the original 2.2 just had a bug where it could save uninitialized data like that, and that was one of the fixes that was made.

	mousex = (raw_mousex - rect.x) * SCREEN_WIDTH_PIXELS / rect.w;
	mousey = (raw_mousey - rect.y) * SCREEN_HEIGHT_PIXELS / rect.h;