Linked by Thom Holwerda on Mon 26th Feb 2018 18:13 UTC
Windows

Flaky failures are the worst. In this particular investigation, which spanned twenty months, we suspected hardware failure, compiler bugs, linker bugs, and other possibilities. Jumping too quickly to blaming hardware or build tools is a classic mistake, but in this case the mistake was that we weren’t thinking big enough. Yes, there was a linker bug, but we were also lucky enough to have hit a Windows kernel bug which is triggered by linkers!

Thread beginning with comment 654148
To read all comments associated with this story, please click here.
NT is still garbage
by tidux on Mon 26th Feb 2018 22:04 UTC
tidux
Member since:
2011-08-13

> Building Chrome very quickly causes CcmExec.exe to leak process handles. Each build can leak up to 1,600 process handles and about 100 MB. That becomes a problem when you do 300+ builds in a weekend – bye bye to ~32 GB of RAM, consumed by zombies. I now run a loop that periodically kills CcmExec.exe to mitigate this, and Microsoft is working on a fix.

What the actual fuck? This would be considered unacceptable on Haiku, let alone Linux or OpenBSD.

Reply Score: 4

RE: NT is still garbage
by avgalen on Tue 27th Feb 2018 10:29 in reply to "NT is still garbage"
avgalen Member since:
2010-09-23

> Building Chrome very quickly causes CcmExec.exe to leak process handles.

What the actual f--k? This would be considered unacceptable on Haiku, let alone Linux or OpenBSD.

This is unacceptable on Windows as well, but it is not something an OS/Kernel should be bothered with. Building Chrome is a usermode process. If that process causes other programs to leak resources that is another usermode process. Usermode processes are configured by default to consume as many resources as are available. In the end that means that one usermode process can consume allmost all resources, which is what you would want in all normal scenarios (no leaks).
As long as the OS can still control those usermode processes the OS is working perfectly.

(ccmexec.exe isn't even present on systems by default, it is a tool that enterprises use to monitor their systems for updates)

The underlying bug is that if a program writes a PE file (EXE or DLL) using memory mapped file I/O and if that program is then immediately executed (or loaded with LoadLibrary or LoadLibraryEx), and if the system is under very heavy disk I/O load, then a necessary file-buffer flush may fail. This is very rare and can realistically only happen on build machines, and even then only on monster 24-core machines like I use.

Well, why wasn't there a unittest for this exact scenario? /s

Edited 2018-02-27 10:42 UTC

Reply Parent Score: 5

RE[2]: NT is still garbage
by tidux on Tue 27th Feb 2018 17:12 in reply to "RE: NT is still garbage"
tidux Member since:
2011-08-13

> Well, why wasn't there a unittest for this exact scenario? /s

You don't need a unit test, just a system design that doesn't constantly thrash disk like a retard. This architecturally can not happen on Linux.

Reply Parent Score: -1