Closed gyroninja closed 4 years ago
Okay, so as it's an issue with wine(tricks) itself (QBeat just calls out to winetricks) I'm not sure what we can do about it.
If we can detect it and recover from within my scripts then great, I'll merge any PR that avoids the issue and doesn't cause regressions for others. If there's nothing we can do then we should try and reproduce outside QBeat/my scripts, and raise the issue up to winetricks.
If I get the time I'll try and reproduce here on a clean setup..Might have encountered it myself but was maybe masked by having lots of ram.
Any suggestions welcome on this one, tagging @Ominitay (Sorry, you've become the wine expert and I need the help ;D)
This is an issue with winetricks dotnet installation and was noted in my issue a while ago. As far as I know, there is nothing that we can do on our end, and rather we need to report it as a bug at the winetricks repo.
We need to find out how to reproduce this first, so @gyroninja needs to do that for us first by giving us their system info including wine version etc. If we are then able to reproduce this on other systems reliably, then we should file an issue in winetricks.
I have been able to reproduce this on my system just by running WINEPREFIX=~/.wine winetricks dotnet461
. Important info below:
Distro: Arch (kernel 5.8.7)
Wine version: wine-5.16
Winetricks version: Tested with both the latest release, and from the master branch.
I'm going to do some more testing, and will report an issue in winetricks later on.
I can reproduce this error as well. Running WINEPREFIX=~/.wine winetricks dotnet461
does it for me.
Wine version is wine-5.16.
Winetricks version is latest release (same results as on master branch).
OS is arch.
The prefix directory doesn't seem to matter. I will report this later today.
but was maybe masked by having lots of ram.
Well it ate like 28 GiB, so it would have required a lot of ram to mask the issue.
needs to do that for us first by giving us their system info including wine version etc.
I am on Manjaro Unstable. Linux: 5.4.63-1-MANJARO wine: wine-5.16 winetricks: 20200412 - sha256sum: 40ff4c67804584b73d4d36153e1f64ca426d739f1790bd748f5ded0865e8cc7f
So we have the same wine and winetricks versions. I'd like to rule out that this is a specifically Arch-based distro before reporting though, so I'll test on a Debian-based system later.
@Ominitay No need, I'm very much Debian-based so happy to test things here (Got a virtual lab if we need to try weird setups)
My specs (laptop in this case)
First installation attempt failed on the 2nd wizard, after a warning about the microsoft installer service not being available Second attempt continued, worked as expected
Saw a few (max 6?) mscors processes during the run, max of 200MB of memory each. After each wizard quit the processes shut down immediately. Might be that the processes just don't shut down cleanly, so the train of mscors starting/stopping during the run just builds up?
So think the possibilities would be:
Ah looks like it's a bug in Wine:
So looks like the workaround is to downgrade Wine to < 5.12 for now
(And if anyone can get a wine-free way of running IPA.exe (for the --patch) step we could avoid these issues...but that wouldn't be easy)
From 49532:
'''It looks like some .net processes hang on termination. All of the threads are doing normal shutdown when on of them calls ExitProcess. Some of the remaining threads receive SIGQUIT from wineserver while holding virtual_mutex (freeing VM from virtual_free_teb) and get force terminated without unlocking it. Meanwhile the thread which called NtTerminateProcess is spared from getting SIGQUIT, and locks forever on NtUnmapViewOfSection on virtual mutex.'''
Yeah, another one of those windows-threading-hang-on-exit conditions..Seen them before in several games and they're a right pain. I recommend patience in general, Wine maintainers should handle it in time :)
So it's a wine regression. Since closing mscorsvw.exe processes doesn't cause any issues, we could probably work around this for now. I'll brainstorm a few approaches and make a PR when I'm happy with it.
@gyroninja Please try using the latest pre-release, and tell us which (if any) errors you come across. If the workaround works as intended, the mscorsvw.exe processes will each be terminated after 1 minute, and you will see messages in your terminal like Killed: [PID]
. Also, there will be no installer wizards anymore.
Calling this one closed, fixed in https://github.com/geefr/beatsaber-linux-goodies/releases/tag/0.5.4
Yeah, sorry about not testing that out. At the time I did not want to break my working install and recently I have been busy.
After the first installer finishes the setup process, it does not bring up the next process but rather starts consuming my system's resources until all of my memory is exhausted. I think it's caused by too many processes being spawned because there is not a single process on the machine using more than a couple percents despite the setup process using tens of GiB of memory. I ended up being able to continue the setup process by doing
pkill mscorsvw.exe
as mentioned in #44 . I needed to execute the command after every installer for the process to continue excluding the final installer.