DavidGoodwin
commented
3 years ago I see this on PHP 7.4 ... for me, it's due to grpc.
The ini stuff here https://github.com/grpc/grpc/issues/20994#issuecomment-552624880 fixes it.
Closed voku closed 2 years ago
DavidGoodwin
commented
3 years ago I see this on PHP 7.4 ... for me, it's due to grpc.
The ini stuff here https://github.com/grpc/grpc/issues/20994#issuecomment-552624880 fixes it.
gsherwood
commented
2 years ago Cross-posting over here to see if anyone is able to test the fix in #3519 to see if it address this bug report.
DavidGoodwin
commented
2 years ago I left https://github.com/squizlabs/PHP_CodeSniffer/pull/3519#issuecomment-1040057274 on #3519 .... I'm not sure it's fixed.
voku
commented
2 years ago I left #3519 (comment) on #3519 .... I'm not sure it's fixed.
@DavidGoodwin
If you use "parallel" execution, then take a look at the different processes, e.g. via top or something like ps aux | grep php and then strace into one of these processes. The main process is still waiting for the child processes, but not every child process is waiting for all other child processes anymore. Can you confirm that?
DavidGoodwin
commented
2 years ago Running :
./vendor/bin/phpcbf --parallel=3 --standard=PSR12 --exclude=Generic.Files.LineLength ./lib/app ./tests
I see the parent stuck at :
strace: Process 1995388 attached
wait4(0, I managed to catch a child early enough on and got this -
newfstatat(AT_FDCWD, "/tmp/phpcs-childTLgqfy", {st_mode=S_IFREG|0600, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0
openat(AT_FDCWD, "/tmp/phpcs-childTLgqfy", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
newfstatat(3, "", {st_mode=S_IFREG|0600, st_size=0, ...}, AT_EMPTY_PATH) = 0
lseek(3, 0, SEEK_CUR) = 0
write(3, "<?php\n $childOutput = array (\n "..., 167) = 167
close(3) = 0
close(2) = 0
close(1) = 0
close(0) = 0
munmap(0x7f99a9800000, 2097152) = 0
munmap(0x7f99a9c00000, 2097152) = 0
munmap(0x7f99a9a00000, 2097152) = 0
munmap(0x7f99a9600000, 2097152) = 0
munmap(0x7f99a9200000, 2097152) = 0
munmap(0x7f99ab96d000, 123888) = 0
munmap(0x7f99ab7c6000, 1729800) = 0
munmap(0x7f99ab98c000, 289184) = 0
futex(0x7f99ac71a340, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7f99ac719140, FUTEX_WAIT_PRIVATE, 0, NULLAnd all children end up hanging on something like -
strace -p 1995396
strace: Process 1995396 attached
futex(0x7f969a746140, FUTEX_WAIT_PRIVATE, 0, NULLIf i run it with : php -d grpc.enable_fork_support=1 it behaves normally and doesn't block/wait forever.
PHP 7.4.27 (cli) (built: Dec 20 2021 21:28:51) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.27, Copyright (c), by Zend Technologies
with Xdebug v3.1.2, Copyright (c) 2002-2021, by Derick Rethansusing the deb.sury.org repo with it's grpc module installed.
The same problem occurs with PHP8.0 (from the same source).
gsherwood
commented
2 years ago @voku has confirmed that this particular issue is resolved. The grpc issue is, I believe, something different and I don't think that's something I have control over. If anyone disagrees, please open a new report and we can track it there.
Describe the bug I don't know if this is a bug or not, but it looks strange:
Some processes seem to do nothing
0 wait4(18694, 0x7ffe6ddd6cbc, WNOHANG, NULL) = 0(strace) but still need max CPU power (top).Code sample Sorry, but the bug can't be shown in a small code sample, you need many files, so that one process is ready before other processes when we call PHP CodeSniffer via
--parallel=X.Custom ruleset
Custom ruleset
```xmlTo reproduce Run PHP CodeSniffer on a big code-base and then take a look at the processes via
strace -p <PID>then you can see that there are processes that makes nothing "wait4" but still need ~ the same CPU power (see via(h)top) as the running processes.Expected behavior If one process is done with his files, then the process does not need to use CPU power anymore, or?
Versions (please complete the following information):
Additional context
ps aux| grep php
sudo strace -p 10766