Bug #62658 [Opn->Fbk]: When enable –with-curlwrappers option, stream_get_contents() may cpu 100%

From: Date: Fri, 28 Sep 2012 19:44:39 +0000
Subject: Bug #62658 [Opn->Fbk]: When enable –with-curlwrappers option, stream_get_contents() may cpu 100%
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-173787@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=62658&edit=1 ID: 62658 Updated by: pierrick@php.net Reported by: sopl dot wang at gmail dot com Summary: When enable –with-curlwrappers option, stream_get_contents() may cpu 100% -Status: Open +Status: Feedback Type: Bug Package: cURL related Operating System: ALL PHP Version: master-Git-2012-07-25 (Git) -Assigned To: +Assigned To: pierrick Block user comment: N Private report: N New Comment: Do you still have this issue ? I tried on my local build and everything work as expected. If it doesn't work could you give me more details about your build ? libcurl version ? Previous Comments: ------------------------------------------------------------------------ [2012-07-25 10:26:16] sopl dot wang at gmail dot com Description: ------------ When enable –with-curlwrappers option, with http(s)/ftp(s)/other curl-wrapped stream protocols, file_get_contents(), stream_get_contents() and alike functions may lead consume 100% cpu cycle on waiting for receive. When strace problem php process, following will be develop: <pre> select(7, [6], [6], [], {15, 0}) = 1 (out [6], left {15, 0}) poll([{fd=6, events=POLLIN}], 1, 0) = 0 (Timeout) select(7, [6], [6], [], {15, 0}) = 1 (out [6], left {15, 0}) poll([{fd=6, events=POLLIN}], 1, 0) = 0 (Timeout) select(7, [6], [6], [], {15, 0}) = 1 (out [6], left {15, 0}) poll([{fd=6, events=POLLIN}], 1, 0) = 0 (Timeout) select(7, [6], [6], [], {15, 0}) = 1 (out [6], left {15, 0}) poll([{fd=6, events=POLLIN}], 1, 0) = 0 (Timeout) select(7, [6], [6], [], {15, 0}) = 1 (out [6], left {15, 0}) poll([{fd=6, events=POLLIN}], 1, 0) = 0 (Timeout) select(7, [6], [6], [], {15, 0}) = 1 (out [6], left {15, 0}) poll([{fd=6, events=POLLIN}], 1, 0) = 0 (Timeout) select(7, [6], [6], [], {15, 0}) = 1 (out [6], left {15, 0}) poll([{fd=6, events=POLLIN}], 1, 0) = 0 (Timeout) select(7, [6], [6], [], {15, 0}) = 1 (out [6], left {15, 0}) poll([{fd=6, events=POLLIN}], 1, 0) = 0 (Timeout) select(7, [6], [6], [], {15, 0}) = 1 (out [6], left {15, 0}) poll([{fd=6, events=POLLIN}], 1, 0) = 0 (Timeout) select(7, [6], [6], [], {15, 0}) = 1 (out [6], left {15, 0}) poll([{fd=6, events=POLLIN}], 1, 0) = 0 (Timeout) </pre> The reason we found is in 'ext/curl/streams.c', function php_curl_stream_read(), line 174: <code> select(curlstream->maxfd + 1, &curlstream->readfds, &curlstream->writefds, &curlstream->excfds, &tv) </code> When select(), writefds always can write and immediate return, no block at here and, upper module will detect that no data could read and re-invoke this function (php_curl_stream_read()), a nonblock loop, lead this consume 100% cpu bug. If the link very slow, this 100% cpu problem may take the system load very high. Test script: --------------- Enable –with-curlwrappers and test: <code> <?php while (true) file_get_contents('http://soplwang.com'); </code> Expected result: ---------------- Expect the behavior like native php does… When strace, native php generate: <pre> poll([{fd=3, events=POLLIN|POLLERR|POLLHUP}], 1, 60000) = 1 ([{fd=3, revents=POLLIN}]) </pre> Actual result: -------------- When strace, generate: <pre> select(4, [3], [3], [], {15, 0}) = 1 (out [3], left {15, 0}) poll([{fd=3, events=POLLIN}], 1, 0) = 0 (Timeout) select(4, [3], [3], [], {15, 0}) = 1 (out [3], left {15, 0}) poll([{fd=3, events=POLLIN}], 1, 0) = 0 (Timeout) select(4, [3], [3], [], {15, 0}) = 1 (out [3], left {15, 0}) poll([{fd=3, events=POLLIN}], 1, 0) = 0 (Timeout) select(4, [3], [3], [], {15, 0}) = 1 (out [3], left {15, 0}) poll([{fd=3, events=POLLIN}], 1, 0) = 0 (Timeout) select(4, [3], [3], [], {15, 0}) = 1 (out [3], left {15, 0}) poll([{fd=3, events=POLLIN}], 1, 0) = 0 (Timeout) ... </pre> ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=62658&edit=1

« previous php.bugs (#173787) next »