Sat Feb 27, 2021 4:14 am
Maybe this bug was fixed/resolved and somebody forgot to mark topic close, maybe after some commit something clicked in Gzdoom and it stop from happening, etc.
In any case, ok, now I have step by step guide how to report it properly.
Sat Feb 27, 2021 4:50 am
But what version are you using? The bug is fixed in LZDoom and it was pretty simple, the code made the old assumption that the file doesn't exist if you cannot open it instead of checking for file existence, then the check itself was broken too on windows. That said this bug is very rare and never happened on any of my machines, you could investigate what processes are running in the background on your system. That's completely irrelevant to fix the bug tough, the code was obviously wrong.https://github.com/coelckers/gzdoom/pull/1236/files
Sat Feb 27, 2021 4:53 am
Are you *sure* that this was the reason or is it just conjecture? Have you ever seen conclusive proof that this actually failed?
Sat Feb 27, 2021 5:05 am
As i said i never got this bug but can be easily reproduced removing permissions from the file before running the engine and then restoring them before exiting, the ini will be overriden. Then there was the _stat problem on windows so i made another PR to use the internal function.
Sat Feb 27, 2021 5:07 am
drfrag wrote:But what version are you using?
Gzdoom 4.5.something with some custom changes, unrelated to file operations.
Tue Mar 02, 2021 2:02 pm
Okay... I think it's related to the Restart button added. I think there's a chance that when it re-opens the program, the previous instance of GZDoom may not yet be closed. This is whenever the parser encounters an error and execution cannot continue, specifically. That was one way I was able to replicate it... Barely. But if I just do "quit" and launch it again manually, it doesn't happen since there are no other instances open.
Maybe that might be it. I'm not entirely sure.
Tue Mar 02, 2021 2:20 pm
I think you are right. The restart button just generates a WM_QUIT message, which later causes an ExitEvent to be thrown, which initiates a controlled shutdown. And one action in a controlled shutfown is - you guessed it - saving the config - while at the same time the new process will try to read the config and is being blocked by the old one which still has the file locked.
I don't think that posting WM_QUIT in this situation is even remotely safe.
So, @drfrag: This is precisely why I never bothered with your workaround - it would have hidden the real problem, making it even harder to find and fix. It is always a bad idea to fix the symptoms without finding the cause.
Tue Mar 02, 2021 2:27 pm
Interesting but that doesn't change the fact that the original source was wrong and FileExists is broken on windows. When pressing restart with my changes you should still get the config error and be able to investigate the problem. And according to previous reports i'm not sure it cannot happen in other situations.
@Major Cooke could you put a runnable sample?
Tue Mar 02, 2021 2:39 pm
Runnable sample? Press "Restart".
Tue Mar 02, 2021 2:44 pm
It doesn't happen all the time. Just sometimes. So it's still as enigmatic as any other.
Tue Mar 02, 2021 3:53 pm
No, that's to be expected. Sometimes the two processes do not overlap their access, sometimes they do. A classic case of unsynchronized access to a non-shareable resource.
Wed Mar 03, 2021 4:11 am
Okay i can't reproduce it with a bad zscript.txt, even restarting many times.
Wed Mar 03, 2021 9:45 am
It's pretty rare when it happens. If anything I'd suggest loading up intensive mods that take a lot of memory for example such as AEons of Death. Maybe it having to unload more may trigger it to occur more often? Just a guess, but perhaps that may cause more overlap.
Wed Mar 03, 2021 9:49 am
drfrag wrote:Interesting but that doesn't change the fact that the original source was wrong and FileExists is broken on windows. When pressing restart with my changes you should still get the config error and be able to investigate the problem.
Your proposal won't change anything. The config file does exist, but it cannot be opened for reading because it's already opened for writing.
Wed Mar 03, 2021 1:49 pm
Precisely, i added a check for file existence but you assume that the file doesn't exist becouse it can't be read. It's a bad habit usually seen in old code.
Are you sure that it cannot happen without pressing the restart button? That said that should be fixed too if it actually happens.
Powered by phpBB © phpBB Group.
phpBB Mobile / SEO by Artodia.