|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #76520 Object creation leaks memory when executed over HTTP
Submitted: 2018-06-22 13:14 UTC Modified: 2018-06-22 14:33 UTC
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: tom dot denbraber at moxio dot com Assigned: nikic (profile)
Status: Closed Package: *Web Server problem
PHP Version: 7.2.7 OS: Debian
Private report: No CVE-ID: None
 [2018-06-22 13:14 UTC] tom dot denbraber at moxio dot com
When creating a large amount of objects without storing them, the memory usage keeps increasing, but only when the script is executed as an HTTP request.
When executed over the CLI, the behaviour is as expected: the memory usage is stable then.

The issue can be reproduced using the php:7.2.x-apache-stretch Docker images and the script below.
The problem does not occur everytime you run the script: most of the times, the first request after you boot the container will not show the problem, but each following request does.

The problem is introduced in PHP 7.2: earlier versions of PHP do not show this problem. 
Creating arrays or scalars instead of objects works as it should and does not retain memory.
Wrapping the loop in a function, to trigger a cleanup after the function has executed does not help.

Test script:
$memory = memory_get_usage();
printf("before iterating, memory %d\n", $memory);

for($i = 0; $i < 1000000; $i++) {
	if (($new_memory = memory_get_usage()) > $memory) {
		$memory = $new_memory;
		printf("iteration %d, memory %d\n", $i, $memory);
	new \stdClass();
printf("after iterating, memory %d\n", memory_get_usage());

Expected result:
before iterating, memory 385728
iteration 0, memory 385760
after iterating, memory 385760

(obtained by running the script over the CLI in the Docker container)

Actual result:
before iterating, memory 378928
iteration 0, memory 379040
iteration 1024, memory 387232
iteration 2048, memory 403616
iteration 4096, memory 436384
iteration 8192, memory 501920
iteration 16384, memory 632992
iteration 32768, memory 895136
iteration 65536, memory 1419424
iteration 131072, memory 2468024
iteration 262144, memory 4565176
iteration 524288, memory 8759480
after iterating, memory 8759480

As you can see, the script goes from around 370 KB to using over 8 MB.

(obtained by running the script over HTTP)


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2018-06-22 14:00 UTC]
-Status: Open +Status: Verified
 [2018-06-22 14:00 UTC]
I found it hard to believe, but it really is reproducible using the built-in server. First request works fine, second request shows increasing memory usage.
 [2018-06-22 14:12 UTC]
-Status: Verified +Status: Analyzed
 [2018-06-22 14:12 UTC]
The problem is that EG_FLAGS_IN_SHUTDOWN is not being reset for the new request, which prevents reuse of object store entries.
 [2018-06-22 14:23 UTC]
Automatic comment on behalf of
Log: Fixed bug #76520
 [2018-06-22 14:23 UTC]
-Status: Analyzed +Status: Closed
 [2018-06-22 14:33 UTC]
-Assigned To: +Assigned To: nikic
 [2018-06-22 14:33 UTC]
To clarify the impact of this issues:

 * Memory is not leaked between requests. The object store is destroyed after each request.
 * Memory is leaked within one request, by preventing reuse of object store buckets. This means that the memory usage of the object store is 8 bytes * number of total objects created, rather than 8 bytes * maximum number of objects used at the same time.

As such, the practical impact is probably not quite as bad as it might initially appear, but may still lead to significantly increased memory usage in some cases.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Mar 02 14:01:34 2024 UTC