php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #76484 emory leakage with CURLOPT_SSL_VERIFYPEER set to TRUE
Submitted: 2018-06-15 16:57 UTC Modified: 2025-06-05 20:57 UTC
Votes:2
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:1 (50.0%)
From: john357smith at gmail dot com Assigned: bukka (profile)
Status: Not a bug Package: cURL related
PHP Version: 7.2.6 OS: Linux
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: john357smith at gmail dot com
New email:
PHP Version: OS:

 

 [2018-06-15 16:57 UTC] john357smith at gmail dot com 
Description:
------------
When cURL is used with CURLOPT_SSL_VERIFYPEER set to TRUE or even without setting it (= default value is TRUE) there is a memory leakage with every call causing memory usage of php process to be constantly increasing.

memory_get_usage() reports still the same value so it must be core problem.

Keep test script running for more than 1 hour to see difference in memory usage (e.g. with top/htop etc.)

After running this script for 24 hours I got 50% of system memory to be used (cca 2GB)!

Test script:
---------------
  error_reporting((E_ALL));

  while (TRUE)
  {
    $url = "https://www.yahoo.com/";

    echo("Fetching $url ... \n");

    $ch = curl_init();
    curl_setopt($ch, CURLOPT_URL, $url);
    curl_setopt($ch, CURLOPT_NOBODY, TRUE);
    curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, TRUE);
    curl_exec($ch);
    curl_close($ch);

    usleep(200000);
  }


Expected result:
----------------
No memory leakage even when script is running forever.

Actual result:
--------------
Memory usage is constantly increasing in time.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-07-25 18:48 UTC] john357smith at gmail dot com 
One month after I created this bug and no feedback? Will somebody look at it?
 [2018-07-25 19:06 UTC] requinix@php.net
-Status: Open +Status: Feedback
 [2018-07-25 19:06 UTC] requinix@php.net 
Tried this with the 7.2.8 and 7.1.20 I have on hand, and with repeated calls but not for a full hour (let alone 24). No leaks.

If you var_dump(memory_get_usage()) do you see an increase after a few requests, or does it actually take on the scale of an hour to see it? What does valgrind have to say?
 [2018-09-08 11:46 UTC] john357smith at gmail dot com
-Status: Feedback +Status: Open
 [2018-09-08 11:46 UTC] john357smith at gmail dot com 
Hi again

Sorry for the late answer I didn't get any email notification about your replay. 

I tried it again with the latest version 7.2.9 compiled with only necessary options. After one hour the memory_get_usage() reports still the same number but consumed virtual memory increased from 290MB to 420MB. Couldn't be problem with leakage in openssl or curl library? I'm using openssl-1.0.2k-8 and curl-7.29.0-42.

Here are screenshots with running process and htop showing memory usage:

https://imgur.com/upfRDl0 - after start
https://imgur.com/kpCUsbV - after 1 hour

Thanks.
 [2018-11-02 07:01 UTC] john357smith at gmail dot com 
Will anybody reply me?
Thanks.
 [2019-03-26 16:21 UTC] mike@php.net 
Cannot reproduce either with a current libcurl.
Might have been an upstream or SSL library issue.
 [2025-06-05 20:57 UTC] bukka@php.net
-Status: Open +Status: Not a bug -Assigned To: +Assigned To: bukka
 [2025-06-05 20:57 UTC] bukka@php.net 
This was probably library bug that is most likely fixed considering that 2 people were not able to recreate it long time ago and we had no other reports about this. I will close this but if you are able to experience it with the latest versions, please open a new GitHub issue and we will look into it.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sat Oct 25 19:00:01 2025 UTC