SDL2: Occasional crash setting Tiles to None (main-sdl2.c line 4023 "graphics.texture != NULL")

[smbhax]

MSYS2-compiled SDL2 front-end, latest Angband code, Windows 11.

I've had the SDL2 front-end crash on me three times in the past two days when setting Tiles to None from the top menu. I've generally been using the Gervais tileset, and I think all three crashes occurred when switching from Gervais to Tiles = None.

The crashes have occurred after changing fonts and tile sizes. I have not been able to find exact reproducible steps, however; in general, it's something like

• Turn tiles on
• Change font or change tile size
• Change tile size or font
• Turn tiles off

I didn't take a close look at the crash window of the first two crashes. Screenshot of the last one attached below. Text says:

Microsoft Visual C++ Runtime Library

Assertion failed!

Program: C:\msys64\home\smbhax\angband\angband.exe
File: main-sdl2.c
Line: 4023

Expression: subwindow->window ->graphics.texture != NULL

(Are the two asserts at that point in the code a debugging thing? When I compile, should I be setting something that would disable assertions?)

[backwardsEric]

Yes, the assertions are related to debugging. You could disable them by adding -DNDEBUG to the flags passed to the compiler (i.e. run make -f Makefile.msys2.sdl2 clean ; make -f Makefile.msys2.sdl2 CFLAGS=-DNDEBUG in the src directory; need the clean step to remove the object files that were generated with assertions enabled). In this case, it's going to crash even if the assertions aren't there, and the crash message will likely be less informative with the assertions disabled.

Based on where it crashed, this is caused by some tile not being cleared, and then the game attempts to redraw it when not in tile mode (similar to the crash you encountered earlier with #5552 ). From the screenshot, I'm guessing this may be related to #5591 as there's pieces of tiles below the status line. In case it's not that, it'd be useful to know what subwindows are open and what the tile multiplier setting is.

[smbhax]

I thought it might be related to #5591 as well, but I couldn't get a crash disabling Tiles every time I had reproduced that bug--so tiles showing below the status bar does not necessarily mean the crash will occur when Tiles are disabled.

Subwindows are Messages, Monster Recall / Object Recall, and Monster List.

Not sure what the tile multiplier was each time; generally I would run Gervais or Shockbolt with multiplier 4x4, but it may have varied a bit during these crashes as I was testing stuff. Come to think of it, I think I was testing #5591 when this last crash occurred, so the multiplier would have been at least x3... Yes, it looks like it was font 12x24x (that would not have been the case in the two previous crashes, however; with those it could have been a downloaded DOS-style font; when this last crash occurred, I had removed all my DOS font settings to make sure I was getting a clean repro for #5591), and tile multiplier 4x3.

Those settings do not guarantee a crash, as it did not crash just now as I was messing with them to verify the settings.

Thanks for the info on asserts, I guess I'll leave them alone for now. : )

[smbhax]

The reproducible SDL2 crash cycling backwards from color 255 (#5597) produces the same crash information as this one does.

[backwardsEric]

In my early comment, I was likely wrong that disabling or removing the assertion wouldn't avoid the crash (at least for #5597 it does; it likely does for this one as well but I haven't reproduced this one running one Linux). #5598 will prevent the crash, but why there's something in the terminal's buffer in this case that looks like a tile still needs to be resolved.