Window freezes when changing clock backwards

[bpasero]

Unfortunately it looks like spdylog is still causing the window to freeze from time to time on Windows. I was for a long time suspecting my change from sync to async dialogs to cause the behaviour but now I see that it might not be the case.

Here is what I did today and what in the past often has caused the renderer (window) to show a dialog that it no longer responds:

• wake up a sleeping Windows 10 VM in parallels that has Code Insiders running (as well as code out of sources)
• check for updates in the Code Insiders version (it downloads the update from today)
• undo a change from git viewlet and confirm it (since I was always suspecting this to originate from my dialog changes, I wanted to trigger a dialog to see if it is reproducible)
• in the version where we run out of sources I did the same from the git viewlet
• meanwhile in Code Insiders acknowledge the update from the gear icon
• now the installer tells that Code Insiders did not correctly shutdown and thus cannot install
• abort the installation
• check process explorer and notice how the Window is still running even though the main process is gone (!)
• open VS and attach to the window process
• pause using the debugger and notice how you always end up in this stack:

Notice how VS indicates that lots of memory gets allocated and freed:

It is worth mentioning that my logs folder for Code Insiders does not contain any new entry for today (4th of January) in the renderer, the last entries are from the day before (3rd of January):

logs.zip

This is a tough one, I cannot easily reproduce. It very often typically happens with the steps above where I come into the office the next day, resume by VMs and check for updates.

Maybe this is related to the fact that VS Code is running over night and spdylog somehow fails to create a new log folder for the new day from the renderer? The weird thing however is that the extension host log folder seems to have an entry from the 4th. But there is no entry for the renderer (e.g. I would expect some entries for the discarding of changes from the git viewlet).

I can also not really understand why this does not happen in stable. Did we change anything in insiders around spdylog?

[bpasero]

I was able to reproduce running out of sources and now the stack reveals a little more:

It looks like what can trigger it is manually changing the time of the OS. In this case I was jumping between 1 day in the future and back to normal while Code was running.

[joaomoreno]

Awesome steps and details!

[joaomoreno]

Steps:

1. Open Code
2. Go back in time in the system settings by any amount
3. To to close the window in the X.

The renderer seems to freeze. The main process seems to be working, you can still run the menus and open new windows.

[joaomoreno]

We're hitting this: https://connect.microsoft.com/VisualStudio/Feedback/Details/1121801

Related:

• https://social.msdn.microsoft.com/Forums/en-US/c72118bb-15fd-4603-b043-d7edb752dea9/timing-bug-with-sleepfor-trylockfor-etc-msft-stl?forum=vclanguage
• https://developercommunity.visualstudio.com/content/problem/61684/stdthis-threadsleep-for-depends-on-system-time.html
• https://developercommunity.visualstudio.com/content/problem/169569/this-threadsleep-for-hangs-when-system-clock-moved.html
• https://developercommunity.visualstudio.com/content/problem/58530/bogus-stdthis-threadsleep-for-implementation.html

Docs on sleep_for:

The standard recommends that a steady clock is used to measure the duration. If an implementation uses a system clock instead, the wait time may also be sensitive to clock adjustments.

Docs on sleep_until:

Blocks the execution of the current thread until specified sleep_time has been reached.

The clock tied to sleep_time is used, which means that adjustments of the clock are taken into account. Thus, the duration of the block might, but might not, be less or more than sleep_time - Clock::now() at the time of the call, depending on the direction of the adjustment. The function also may block for longer than until after sleep_time has been reached due to scheduling or resource contention delays.

[joaomoreno]

I've contacted a dev in VS Libs for help.

[sandy081]

Good job @joaomoreno

[joaomoreno]

VS reports that the issue is not yet fixed, unfortunately.

[joaomoreno]

Created PR for spdlog: gabime/spdlog#610

[joaomoreno]

Verified in dev that it doesn't freeze any more when changing time back.