USDX
USDX copied to clipboard
UltraStar-Deluxe
Carousel lets game crash with a high number of songs
Please, do not create duplicate issues
Actual behaviour
If the carousel mode is selected for the song display, the game randomly crashes with 20k+ songs loaded. This does not happen with any other mode or with less songs (7,5k tested).
Expected behaviour
Game should not crash.
Steps to reproduce
Load game with 20k+ songs Select carousel for display mode Scroll through the songs After a few seconds the game will crash without any error or any entry in the error.log.
Details
Provide some additional information:
- USDX version: 2023.04
- Operating System + version: Windows 10, latest
I also see random crashes on macOS with far less songs (~400) while moving around on the carousel after a few seconds the preview video has started. I get this random errors:
An unhandled exception occurred at $0000000101928F08:
EAccessViolation: Access violation
$0000000101928F08
$00000001010DD88C
the hex are always different.
Dunno if related but I get crashes too with 2023.4 and 2023.5 in roulette with only ~100 songs. Here is an error message:
There is nothing in Error.log
The macOS hex values are useless because of ASLR. I wonder why it isn't able to resolve the addresses.
I'm relieved that it crashes as well with v2023.4. That rules out 99a8d36cd6653a88be064d02d7aea66933e94f00 as the culprit.
Are we maybe missing an SDL_LockSurface?
If ASLR being enabled causes a crash, then that means there is some memory overflow or reading outside of assigned array bounds or similar. ASLR just makes it visible in that case because not being able to resolve the physical memory address makes it fail instead of reading some random memory within the process's own space.
I did not want to imply that ASLR caused the crash. ASLR just makes the debug output useless if the Free Pascal runtime is unable to resolve symbols.
My best bet still is that the surface needs locking for glTexImage2D to be able to access the pixels. Not all surfaces need locking. Only those where SDL decided to use RLE compression do.
@AlpenAalAlex, can you test if this build still crashes?: https://ci.appveyor.com/project/s09bQ5/usdx/builds/46991121/job/vdww9nfqmfl5c36f/artifacts
And can you check if the Error.log file contains any lines ending in [TTextureUnit.LoadTexture]?
In your case it doesn't crash when accessing the pixels. It crashes when reading the pixels pointer from the structure pointed to by TexSurface. So SDL must have returned a NULL pointer when USDX wanted to convert the surface to its final format.
Not at all - it just closes in my case. Could not test it with 2023.05 yet.
@s09bQ5
@AlpenAalAlex, can you test if this build still crashes?
Not so far. I tested twice for about 20 minutes. After which in both cases most videos would no longer load or show a freeze frame.
And can you check if the Error.log file contains any lines ending in
[TTextureUnit.LoadTexture]?
ERROR: Could not load texture: "" with type "Transparent" [TTextureUnit.LoadTexture] ERROR: Could not load texture: "C:\Program Files (x86)\UltraStar Deluxe 2023 test\themes\Modern[rap]notesRight.png" with type "Colorized" [TTextureUnit.LoadTexture] ERROR: Could not load texture: "B:\UltraStar Songs\songs\ ... \1200x1200bf-60.jpg" with type "Plain" [TTextureUnit.LoadTexture] ERROR: Could not convert surface [TTextureUnit.LoadTexture]
I'm running the game in windowed mode
The Could not convert surface case is the one that would have crashed previously.
Are you maybe running low on RAM? Or are we hitting the limit of 32 bit processes? I can't see any memory leak when running it here.
I am not running low on RAM. But this behaviour consistently occurs once the game requires about 1.2GB of RAM. The more videos I watch in song selection the more RAM is required.
I can't see any memory leak when running it here.
I take that back. There were a few.
@AlpenAalAlex, please try https://ci.appveyor.com/project/s09bQ5/usdx/builds/47023474/job/09gmrxa24tahqjke/artifacts