osu!lazer freezes/crashes on certain beatmaps at certain points

[magicnat]

Describe the bug:

Certain points in some beatmaps appear to freeze osu!lazer. The behavior is similar to what being described in #2457 and #11691: rendering freezes while inputs and audios works just fine. The game un-freeze itself after ~10 seconds. Spamming inputs during the freeze appears to crash the game sometimes.

The beatmap that I can reproduce the freeze constantly is 1264972 at 0:52.

Screenshots or videos showing encountered issue:

Sorry. I cannot really reliably capture this.

osu!lazer version:

2021.524.0.0 on macOS 11.2.3 (20D91)

Logs:

logs.tar.gz

As mentioned before, spamming inputs during freeze sometimes crash the game. The crash report generated by macOS (osu!_2021-05-24-194559_nato-macbook.crash) is also attached.

Snippet from the os-generated crash report indicates that this may be some sort of GPU issue:

Application Specific Signatures:
Graphics hardware encountered an error and was reset: 0x00000002

I'm using Radeon Pro 5300M with an external monitor (Dell S2417DG) via DP. The freezing issue also exists when using the integrated graphics. I however can't get the game to crash by spamming inputs when using integrated graphics.

[peppy]

Please create a spin dump during the freeze using activity monitor.

[magicnat]

Please find the spindump here and here.

I'm using autoplay for both of the dumps. In both cases the game freezes on 0:52 of 1264972.

I also noticed that:

• The entire macOS kind of freezes with the game whenever it freezes. Whenever the game freezes, it will take a while for the spindump to start after I clicked on it, or the progress bar will just stop if the the OS is taking spindump.
• The freeze tends to happen after a few games; if I play right after the game start, it can finish without any problem. From my observation, the freezes only happen if the game is consuming > 1.3 GB of memory (as reported by the "Real Memory" column in Activity Monitor).

I started the first dump after immediately after the freeze, and the second dump two seconds before the freeze. Although in both cases the entire macOS appears to freeze with the game, so I'm not sure if it has sampled anything useful.

List of beatmaps triggering freezes:

• 696225 0:56
• 184819 0:15
• 1117251 0:23
• 1264972 0:52

The game freezes and only freezes at the points listed above. In autoplay, jumping by clicking the progress bar will also trigger the freeze as the "fast-forward" (?) reaches the points listed above.

[smoogipoo]

Are you able to compile osu! + osu!framework yourself? If so, try testing with https://github.com/ppy/osu-framework/pull/4462

[magicnat]

Are you able to compile osu! + osu!framework yourself? If so, try testing with ppy/osu-framework#4462

I can. I will build and test this to see if anything changes.

[magicnat]

Unfortunately the problem still persists. I'm building from https://github.com/ppy/osu/commit/6263ebf9da15fb142a57129efe34eb4cbbdb7522 and https://github.com/ppy/osu-framework/commit/2f48e8ab8cd442c67faecb1d252e47dfa4c4f93c.

I can reproduce the freezes with the beatmaps listed here pretty stablely.

[peppy]

Just to confirm, you are using the local framework checkout procedure? https://github.com/ppy/osu-framework/wiki/Testing-local-framework-checkout-with-other-projects

[magicnat]

Just to confirm, you are using the local framework checkout procedure? https://github.com/ppy/osu-framework/wiki/Testing-local-framework-checkout-with-other-projects

Yes, I did followed the procedure:

``` nat@nato-macbook ~/projects/osu (git)-[master] % dotnet list osu.Game/osu.Game.csproj reference Project reference(s) -------------------- ..\..\osu-framework\osu.Framework\osu.Framework.csproj nat@nato-macbook ~/projects/osu (git)-[master] % cat osu.Desktop.slnf { "solution": { "path": "osu.sln", "projects": [ "osu.Desktop\\osu.Desktop.csproj", "osu.Game.Benchmarks\\osu.Game.Benchmarks.csproj", "osu.Game.Rulesets.Catch.Tests\\osu.Game.Rulesets.Catch.Tests.csproj", "osu.Game.Rulesets.Catch\\osu.Game.Rulesets.Catch.csproj", "osu.Game.Rulesets.Mania.Tests\\osu.Game.Rulesets.Mania.Tests.csproj", "osu.Game.Rulesets.Mania\\osu.Game.Rulesets.Mania.csproj", "osu.Game.Rulesets.Osu.Tests\\osu.Game.Rulesets.Osu.Tests.csproj", "osu.Game.Rulesets.Osu\\osu.Game.Rulesets.Osu.csproj", "osu.Game.Rulesets.Taiko.Tests\\osu.Game.Rulesets.Taiko.Tests.csproj", "osu.Game.Rulesets.Taiko\\osu.Game.Rulesets.Taiko.csproj", "osu.Game.Tests\\osu.Game.Tests.csproj", "osu.Game.Tournament.Tests\\osu.Game.Tournament.Tests.csproj", "osu.Game.Tournament\\osu.Game.Tournament.csproj", "osu.Game\\osu.Game.csproj", "Templates\\Rulesets\\ruleset-empty\\osu.Game.Rulesets.EmptyFreeform\\osu.Game.Rulesets.EmptyFreeform.csproj", "Templates\\Rulesets\\ruleset-empty\\osu.Game.Rulesets.EmptyFreeform.Tests\\osu.Game.Rulesets.EmptyFreeform.Tests.csproj", "Templates\\Rulesets\\ruleset-example\\osu.Game.Rulesets.Pippidon\\osu.Game.Rulesets.Pippidon.csproj", "Templates\\Rulesets\\ruleset-example\\osu.Game.Rulesets.Pippidon.Tests\\osu.Game.Rulesets.Pippidon.Tests.csproj", "Templates\\Rulesets\\ruleset-scrolling-empty\\osu.Game.Rulesets.EmptyScrolling\\osu.Game.Rulesets.EmptyScrolling.csproj", "Templates\\Rulesets\\ruleset-scrolling-empty\\osu.Game.Rulesets.EmptyScrolling.Tests\\osu.Game.Rulesets.EmptyScrolling.Tests.csproj", "Templates\\Rulesets\\ruleset-scrolling-example\\osu.Game.Rulesets.Pippidon\\osu.Game.Rulesets.Pippidon.csproj", "Templates\\Rulesets\\ruleset-scrolling-example\\osu.Game.Rulesets.Pippidon.Tests\\osu.Game.Rulesets.Pippidon.Tests.csproj", "../osu-framework/osu.Framework/osu.Framework.csproj", "../osu-framework/osu.Framework/osu.Framework.NativeLibs.csproj", "../osu-framework/osu.Framework/osu.Framework.csproj", "../osu-framework/osu.Framework/osu.Framework.NativeLibs.csproj" ] } } nat@nato-macbook ~/projects/osu (git)-[master] % git log -n1 commit 6263ebf9da15fb142a57129efe34eb4cbbdb7522 (HEAD -> master, tag: 2021.524.0, origin/master, origin/HEAD) Merge: 3b4fbe22f0 eeda33a453 Author: Dan Balasescu Date: Mon May 24 23:33:49 2021 +0900 Merge pull request #12495 from peppy/localisation-proof-of-concept Add language selection and general structure for localisation support nat@nato-macbook ~/projects/osu (git)-[master] % ../osu-framework nat@nato-macbook ~/projects/osu-framework (git)-[master] % git log -n1 commit 2f48e8ab8cd442c67faecb1d252e47dfa4c4f93c (HEAD -> master, origin/master, origin/HEAD) Merge: 137367131 75a9bbe2a Author: Dean Herbert Date: Tue May 25 13:01:59 2021 +0900 Merge pull request #4462 from smoogipoo/flush-after-fbo-bind Flush framebuffer after FBO bind on macOS ```

[peppy]

Also with the time based reproduction: does it change anything if you watch autoplay and skip directly to the time?

Either way, I can confirm that I can't reproduce this here, so it's likely something hardware specific.

[magicnat]

Also with the time based reproduction: does it change anything if you watch autoplay and skip directly to the time?

Yes - it will freeze no matter how it reaches that time. Even if I don't skip directly to the time; as long as the autoplay passes the time (even during skipping forward or backward), the game freezes. Here's a recording demoing the behavior.

[peppy]

Does it also freeze a second time if seeking back before the time then letting it play again?

[magicnat]

Does it also freeze a second time if seeking back before the time then letting it play again?

Yes. Getting to those points will always freeze the game. If I skip back to an early time, it will actually freeze twice - once on the way back and once when it play that part again.

[smoogipoo]

One other thing I'd like you to try is a branch on my fork: https://github.com/smoogipoo/osu-framework/tree/disable-fbos

Note that a lot of the game will be broken (no backgrounds, volume meters, etc), but you'll still be able to get to those same points in the maps.

[magicnat]

One other thing I'd like you to try is a branch on my fork: https://github.com/smoogipoo/osu-framework/tree/disable-fbos

With that it seems like the game indeed no longer freezes (at least, not after 45 min of constant autoplays; normally the freezes start happening around 5~10 min in the game).

And when running w/ fbos, I sampled the game during the freeze with dotTrace. I didn't see anything unusual, but just in case there's something useful I missed: dotnet - [2021-05-25 01-55-06].dtp.zip.

[smoogipoo]

Hmm ok, that narrows it down quite a lot. In that case, when running with FBOs, does enabling "Bypass front-to-back render pass" in the settings fix it?

[magicnat]

Hmm ok, that narrows it down quite a lot. In that case, when running with FBOs, does enabling "Bypass front-to-back render pass" in the settings fix it?

Didn't work. It still freezes at the same places.

[smoogipoo]

I've updated my o!f branch: https://github.com/smoogipoo/osu-framework/commit/aa830996e61afdfd37a5fdae61d17d9f296280d3 see if that still crashes (ignore texture corruption on sliders).

[magicnat]

I've updated my o!f branch: smoogipoo/osu-framework@aa83099 see if that still crashes (ignore texture corruption on sliders).

This works - autoplay-ed for another 45 minutes without any freeze or crash.

[smoogipoo]

Could you try turning off slider snaking and trying without my branch?

[magicnat]

I didn't help. That actually one of the first things I tried as I noticed all freezes seems to happen around sliders; should have mentioned it, sorry.

I also managed to find a point that always freezes the game when using the current master branch, even if the game is just started: 0:56 of 696225.

[smoogipoo]

Alright, for now I just have two more o!f branches to try out: https://github.com/smoogipoo/osu-framework/tree/rbo-1 https://github.com/smoogipoo/osu-framework/tree/rbo-2

Do either of these work? If not it might be that I'm looking in the wrong place and the issue is actually in FBOs, but I'll need to go through it all again. Some people suggest deleting and recreating the entire FBO when sizes change - without snaking there's only one change of size happening (initial 1x1 -> final size) so it's still possible that it's going wrong.

[magicnat]

Sure, I will try those too. In the meanwhile, here are some interesting findings playing with 696225:

• play w/ HD: still freezes
• play w/ HR: no freeze - at least not at this particular point
• changing CS:
  • CS 2.5: no freeze
  • CS 3.5: freezes
  • CS 4.5: freezes
  • CS 5.0: no freeze

[magicnat]

Sadly neither of them worked; it seems the problem might actually be in FBOs.

[0x41c]

I mentioned this crash back here, and it's still a thing on recent versions. I'm on macOS also, and I have the ability to give a stack trace. Happens too often to count. I just saw this though and since it was marked as fixed while still encountering crashes I thought this might need to be revisited.

[AkiSakurai]

Switching to use ANGLE with metal backing renderer fixes the issue for me, however the performance is not great, around 25 fps when scrolling the beatmap list.

//Set before SDL_CreateWindow
SDL.SDL_GL_SetAttribute(SDL.SDL_GLattr.SDL_GL_CONTEXT_PROFILE_MASK, SDL.SDL_GLprofile.SDL_GL_CONTEXT_PROFILE_ES);

export DYLD_LIBRARY_PATH=/Applications/Google\ Chrome.app/Contents/Frameworks/Google\ Chrome\ Framework.framework/Libraries/
export ANGLE_DEFAULT_PLATFORM=metal
dotnet run --project  ./osu.Desktop/osu.Desktop.csproj -c Release

[peppy]

We'll be switching to metal soon, which should resolve this in that case.

[peppy]

Should be resolved.