Author |
Message |
kathrine
Joined: 2011-10-07 10:39:20 Posts: 181
|
Hello Henri, not sure if it is a viewer or AMD driver problem, but i noticed extremly slow shutdowns of the viewer recently. Is this a known problem? A few seconds delay, ok, happens, due to all the destructors cleaning up etc, but minutes seems like something is stuck and waiting for a timeout or so. Any idea what log settings might help to find out? Maybe i should simply unpack a debugger/profiler and take a closer look. For example today it took nearly 4 MINUTES to stop the viewer after hitting the "quit" button.
|
2022-10-23 11:57:46 |
|
|
Henri Beauchamp
Joined: 2009-03-17 18:42:51 Posts: 5545
|
For me (and for the rare times when I actually "use" the viewer under Windoze, like what happened last week, when verifying that the UI textures corruption got fixed), the shutdown process, while (much) slower than under Linux (where it takes at worst a few seconds and usually under 2 seconds), the viewer definitely does not need minutes to shut down (tested under Win 7 Ultimate + ESU and Win 11 Pro 21H2), but at most 30 seconds or so...
This said, my Windows installations have been the subject of a very stringent diet, with removal of all "accessories" (including Windows Defender, Search, etc).
I would personally suspect Windows Defender (or any other "real time" anti virus) to be the culprit... You could try and exclude the viewer cache directories from Defender and Search, for example...
|
2022-10-23 15:33:47 |
|
|
Ibrew Meads
Joined: 2010-03-14 21:12:58 Posts: 86
|
I have noticed long shutdown times on Linux when memory is tight and the system has been paging to disc for a while. It can take several minutes to shut down and exit as it resolves all the swapped pages and clears things up. But this is not in any way the viewer's fault. I just need a new computer.
|
2022-10-23 21:49:12 |
|
|
kathrine
Joined: 2011-10-07 10:39:20 Posts: 181
|
Sure, when memory is tight, you swap out memory. And that memory needs to be swapped back in to run the destructors of all those objects.
Thats fine, in general. Some systems like some games (or Windows with fast shutdown) optimize away those destructors by simply not cleaning up and just doing a controlled crash. Thats technically a memory leak, but the Memory Management Unit or operating system cleans up the mess later. You hide memory leaks in your code that way, so its only a late optimization to do.
In my case memory is plentiful, but probably some parts block each other shutting down. Henri's suggestion about virus scanners is probably a good one, those tend to do that. I'll investigate in that direction.
|
2022-10-23 22:01:58 |
|
|
Henri Beauchamp
Joined: 2009-03-17 18:42:51 Posts: 5545
|
Well, that's a dirty hack that I had to recourse to for the experimental branch since otherwise, something related with libepoxy (likely a threading issue with probably a deadlock or infinite loop somewhere in Windows or the drivers) causes the viewer process to never exit, so the last thing I am doing ( after a proper structures cleanup however) is a call to "TerminateProcess(GetCurrentProcess(), exit_code)", so to suicide the process... You could try v1.30.1 and see if it exits faster than v1.30.0 for you (it should at least exit immediately after the logged "Goodbye")...
|
2022-10-24 16:47:33 |
|
|
kathrine
Joined: 2011-10-07 10:39:20 Posts: 181
|
Some new insights. I used Windows Performance Recorder (WPR) to capture a trace of the system during the shutdown of the viewer. It seems the quite sequence causes a bunch of crash recorder WERFault.exe processes to get created, and only after that storm (and memory dumping) subsides, the viewer finally shuts down. This is a part of it displayed in the Windows Performance Analyzer: In the lower pane, one notices the CoolVLViewer that has a lot of WERFault subprocesses. Those get spawned when Windows notices an appcrash somewhere. Its just strange to see so many of them. In the upper pane, it shows the CPU usage, the usage spikes a bit before the WER process gets created, then drops again, until the next process gets created. I'll try to figure out whats happening there.
|
2022-10-24 19:52:36 |
|
|
Henri Beauchamp
Joined: 2009-03-17 18:42:51 Posts: 5545
|
Well, that's interesting, and somewhat surprising since the viewer unregisters itself from the Windows Error Reporting (WER) (and reports it in the log via a "Windows error reporting disabled successfully." message), and uses its own crash dump routine (that got an anti-reentrance security check), which should get triggered in case of any crash on exit...
|
2022-10-24 21:17:10 |
|
|
kathrine
Joined: 2011-10-07 10:39:20 Posts: 181
|
Indeed, it is pretty strange. The log shows the mentioned "Windows error reporting disabled successfully." The WERFault cascade seems to happen in a pause in the log, right after: So, maybe its some parts of the LLImageGLThread shutdown that causes WERFault to trigger.
|
2022-10-24 22:35:16 |
|
|
Henri Beauchamp
Joined: 2009-03-17 18:42:51 Posts: 5545
|
Likely in the OpenGL driver then... Not seeing any such problem here.
|
2022-10-24 22:36:40 |
|
|
kathrine
Joined: 2011-10-07 10:39:20 Posts: 181
|
I guess i found the issue. After attaching a debugger i noticed i still had GL debugging activated, so the code entered log_glerror() and promptly crashed there. Maybe thats new or wasn't tested yet, but glGetError() crashes when no current GL context is around. So i added a quick check (probably wrong for Linux... like this), and the WERFaults spawn stopped, despite GL debugging being enable. It also speeds up the shutdown again, so it is quick. Not sure if this is a bug or just bad usage, but i guess the logging should check if a context exists.
|
2022-10-25 00:01:58 |
|
|