Closed magicnat closed 1 year ago
Please create a spin dump during the freeze using activity monitor.
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:
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:
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.
Are you able to compile osu! + osu!framework yourself? If so, try testing with https://github.com/ppy/osu-framework/pull/4462
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.
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.
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
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:
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.
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.
Does it also freeze a second time if seeking back before the time then letting it play again?
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.
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.
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.
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?
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.
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).
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.
Could you try turning off slider snaking and trying without my branch?
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.
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.
Sure, I will try those too. In the meanwhile, here are some interesting findings playing with 696225:
Sadly neither of them worked; it seems the problem might actually be in FBOs.
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.
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
We'll be switching to metal soon, which should resolve this in that case.
Should be resolved.
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:
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.