Closed rdeago closed 2 months ago
Thanks for looking into this! 100ms is indeed overkill. The scenario this guards for is the scenario where a user launches PHPStan, then closes the editor mid-check and re-launches the editor without having rebooted the machine. It should then kill the remaining child PIDs in the zombie killer. I think doing two checks (one at start, one after PHPStan has possibly spawned workers) is enough for this relatively rare case.
Fix has been published in v3.2.7
@SanderRonde
I am on v3.2.7
and am still seeing out of control creation of wmic processes. Only happens within VSCODE, if i call phpstan from the command line, all is well.
Hmm interesting, will look into this when I'm on a windows machine again. It should only query the process list 3 times per check now (once during creation, once after 10s, once during killing). And it should only create a single wmic process. Just to get an idea, how out of control is it? As in how many processes are being spawned and how much CPU is being used? Might help me spot it once I manage to reproduce it.
I can not count them, because they are so rapidly created and destroyed that the whole system hangs while the scan is active. CPU is an i7-10850H at 100% usage.
PHPSTAN-Settings:
"phpstan.binPath": "C:\\Program Files\\Composer\\vendor\\bin\\phpstan.bat",
"phpstan.configFile": "C:\\Work\\Config\\phpstan.neon",
"phpstan.memoryLimit": "4G",
"phpstan.timeout": 50000,
"phpstan.checkValidity": true,
"phpstan.showProgress": true,
Just in case it might help, I tried changing the 100-millisecond timeout of version 3.2.6 to 999 milliseconds, without any other modification.
(Why 999? Because I used a hex editor on the minimized distribution 😁)
The flood of WMICs decreased accordingly, of course.
So there seems to be something in version 3.2.7 that triggers ps-tree way more frequently than anticipated... but what? 🤔
Oh wow I'm stupid... I've used setInterval(..., 0)
instead of setTimeout(..., 0)
. No wonder it's spawning so many instances...
Will fix immediately. Thanks for flagging!
OMG setInterval
! I stared at that piece of code for like ten minutes and it totally eluded me. 🙈
Oh wow I'm stupid
Welcome to the club! 🤣
Fix is live under version 3.2.8
!
Yeah I had the exact same, was thinking "how could 2 calls possibly do more than one every 999ms". Surprised this didn't cause a massive influx of github issues.
I guess people's PCs were too busy querying WMI to let them open issues on GitHub. 🥲
Seems fixed to me now. Thank you for the really quick response. 👍
While investigating #103 on my Windows 11 system, I noticed dozens of
WMIC.exe
instances spawn during each run of PHPStan. They were so pervasive as to makeWmiPrvSE.exe
, the service WMIC uses to query system information, take up to 65% (once even 94%) of a 32-thread, 13th-gen Core i9.I eventually found out what's spawning WMIC like crazy: it's ps-tree, called by the
Process
class every 100ms (the call to ps-tree is actually in function_getChildPids
, some lines below).May I suggest to increase the checking interval in
Process::constructor
? 100 milliseconds look pretty overkill to me. 1 second should be good enough as a resolution for process timeouts, especially when checks come at such a cost in terms of performance.