Crash when toggling Windows desktop view

[Toranks]

Game and System Information

The Battle for Wesnoth version 1.17.13 x86_64
Running on Microsoft Windows 7 Service Pack 1 (6.1.7601) x86_64
Distribution channel: Steam

Libraries

Boost: 1.80
Lua: 5.4.4
OpenSSL/libcrypto: 1.1.1s (runtime 1.1.1s)
Cairo: 1.17.6 (runtime 1.17.6)
Pango: 1.50.11 (runtime 1.50.11)
SDL: 2.24.1 (runtime 2.24.1)
SDL_image: 2.6.2 (runtime 2.6.2)
SDL_mixer: 2.6.2 (runtime 2.6.2)

Features

Lua console completion: yes
Win32 notifications back end: yes

Current video settings

SDL video drivers: [windows] dummy
Window size: 1920x1080
Game canvas size: 1920x1080
Final render target size: 1920x1080
Screen refresh rate: 60
Screen dpi: 96.00x96.00
Renderer: direct3d (hw)
Maximum texture size: 16384x16384
VSync: on

Current audio settings

SDL audio drivers: [wasapi] directsound
Number of channels: 2
Output rate: 48000 Hz
Sample format: signed 16 bit little-endian
Sample size: 4096 bytes

Description of the bug

When you do alt+tab to desktop on any moment, the game crashes. This only happens with the game configured to fullscreen and when changes to desktop, not to any other window or program.

Steps to reproduce the behavior

• Enter the game on fullscreen
• Do alt+tab and consecutive tab until you select dektop
• APPCRASH

Expected behavior

No response

Additional context

Reported first on the forum:
https://forums.wesnoth.org/viewtopic.php?p=680202#p680202

[Wedge009]

Marking as confirmed only because this is from a separate report on the forums and Toranks is able to replicate it.

I have tested both the 1.17.13 release (downloaded from sourceforge.net) and my MSVC/cmake-compiled builds from 1.17.13+dev @ 1bbce8a. Tested both Windows 7 and 10, and also made sure the program started in full-screen mode, not just switching to full-screen after starting in windowed mode. I cannot replicate this anywhere. Just for the sake of it, I also checked on Linux - nothing.

Is it possible it's specific to a Steam launch? As far as I know, 'full-screen' in Wesnoth is just a borderless window set to display at the full resolution of a given monitor, so as @Pentarctagon said in the forum thread, there really isn't anything different that Wesnoth is doing outside of making the relevant call to SDL. On the other hand, if this only happens when launched from Steam, maybe the Steam overlay is doing something weird?

[Wedge009]

Okay, I completely missed the part about specifically selecting the Windows 7 desktop 'window'. I don't see any 'desktop' option in Windows 10, so this looks specific to Windows 7.

Edit: Behaviour in windowed mode seems less easy to replicate than in full-screen mode. I can also replicate it with 'windows' + D (for desktop) as a short-cut.

[Toranks]

Just in case, this problem occurs without steam started. Although I have downloaded it from steam, I don't have steam started (not even in background), I start the executable of wesnoth.exe directly.

[Wedge009]

Yeah, it's clearly not Steam-related now that I can see how to replicate it. It may not be an issue in Wesnoth as 1.16.8 release says the 'fault' is in SDL2.dll (although I don't know why it thinks the application version is 1.16.3...)

[Wedge009]

While Windows 10 doesn't have a desktop view option in the Alt-Tab window switching functionality, the issue can be replicated there by using the Windows+D short-cut. There's no crash dialogue, however, Wesnoth simply disappears.

[Wedge009]

The problem is a divide-by-zero exception occurring in video::update_framebuffer():

wesnoth/src/video.cpp

Lines 229 to 234 in bf5befc

	// Find max valid pixel scale at current output size.
	point osize(window->get_output_size());
	int max_scale = std::min(
	osize.x / preferences::min_window_width,
	osize.y / preferences::min_window_height);
	max_scale = std::min(max_scale, preferences::max_pixel_scale);

osize (I'm guessing it's meant to represent output size) is (0,0) when Windows desktop view is toggled. Thus, even if I clamp max_scale to preferences::min_pixel_scale after this code snippet, there is just another divide-by-zero issue somewhere else further down the code, because it's trying to render to a zero-sized frame.

But this code is for 1.17.x, so why is the issue also happening for 1.16.x? sdl::window::get_output_size() is the same for both 1.17 and 1.16, so it may be for the same reason that a (0,0) is being returned. (I can't debug 1.16 Windows builds due to #7217 so I can't check right now.)

wesnoth/src/sdl/window.cpp

Lines 107 to 113 in bf5befc

	SDL_Point window::get_output_size()
	{
	SDL_Point res;
	SDL_GetRendererOutputSize(*this, &res.x, &res.y);
	return res;
	}

It turns out that SDL_GetRendererOutputSize() only starts returning (0,0) when in Windows desktop view (as opposed to the application window just being minimised) only from SDL 2.24.0 onwards. I was prompted to investigate this when I noticed that release 1.17.7, which is packaged with SDL 2.0.22, did not exhibit the crash, yet it does include the pixel scaling code in update_framebuffer(). Similarly, I noticed 1.16.8 release, like 1.17.13 release, is packaged with SDL 2.24.1.

https://wiki.libsdl.org/SDL2/SDL_GetRendererOutputSize does not show any indication of when/how a (0,0) result might be given. But given that a non-zero result seems to be returned for SDL 2.0.22 and (0,0) is returned from 2.24.0 onwards, I wonder if it's an issue - intentional or otherwise - with SDL_GetRendererOutputSize().

[Wedge009]

I just made a quick check: when SDL_GetRendererOutputSize returns (0,0) for the width/height, it's also returning 0 indicating no error conditions.

[Wedge009]

Marking as upstream for now, since simply switching to SDL 2.0.22 removes the issue. Of course, using older SDL will re-introduce #4508 - it seems like there's been some internal overhaul of Windows window handling starting with SDL 2.24.0.

[Wedge009]

@Pentarctagon SDL team has put in place a work-around to return the last known dimensions when a Windows application is in this situation (Windows desktop view active), to be included in 2.26.5 release scheduled around 1st April. I grant this isn't a crippling bug (unless one happens to be fond of using Windows desktop view), but what's involved with bumping Windows builds to a newer SDL? Is it waiting for vcpkg to pick up SDL 2.26.5 and then updating our 'baseline' accordingly? Is it acceptable to leave other platforms alone with respect to their SDL dependency?

[Pentarctagon]

It pulls in whatever is available in the msys2 release that's used for the docker image.

[Wedge009]

So it may be a while before it becomes available, then.

[Pentarctagon]

Updating it isn't hard and it seems like they keep pretty up to date with the SDL2 versions if they've already gotten to 2.24, so I assume it won't be more than a month or two after the fix gets to SDL2.

[Wedge009]

It looks like the recently released SDL 2.26.5 doesn't have this issue. I compiled master @ 39deda9 and just dropped their binary to the working directory and I wasn't able to replicate the crash. I re-confirmed the crash with their SDL 2.26.4 DLL.

[Pentarctagon]

Can this be closed then?

[Wedge009]

Wesnoth is still packaging SDL 2.26.3 - at least last time I checked a few days ago.

[Pentarctagon]

Ah, alright. It should be fixed as part of #7925 then, since the msys2 image needs to be updated for that anyway (whenever a new version of msys2-installer is released).

[Wedge009]

This could have been resolved for a while now, but official 1.17.25 Windows release packages SDL 2.28.4, so closing.