php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #65562 memory leak in zend_parse_arg
Submitted: 2013-08-26 20:23 UTC Modified: 2021-01-17 04:22 UTC
From: rrh at newrelic dot com Assigned: cmb (profile)
Status: No Feedback Package: Performance problem
PHP Version: 5.5.3 OS: all
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: rrh at newrelic dot com
New email:
PHP Version: OS:

 

 [2013-08-26 20:23 UTC] rrh at newrelic dot com
Description:
------------
Function zend_parse_arg leaks memory, as discovered when I ran valgrind with php test cases designed to exercise a module we wrote.

zend_parse_arg calls zend_parse_arg_impl.  Unfortunately, not all control flow paths to the return in zend_parse_arg call efree to free up the memory allocated by zend_parse_arg_impl to hold the error string.  In my case, quiet != 0, so the lone efree (which has 2 additional guards) is not called.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-08-26 20:53 UTC] johannes@php.net
-Status: Open +Status: Feedback
 [2013-08-26 20:53 UTC] johannes@php.net
Please provide compilable code showing the issue. In general: We don't consider issues which can't be triggered by userspace code as bug but expect extension authors to provide patches to improve PHP.
 [2013-08-26 21:21 UTC] rrh at newrelic dot com
-Status: Feedback +Status: Open
 [2013-08-26 21:21 UTC] rrh at newrelic dot com
I didn't provide code to show the issue because the issue is almost certainly 
independent of my module extension, and a quick inspection of the code looking at 
the control flow paths would show that efree isn't called on all paths leading to 
a return from the function.
 [2013-08-26 22:54 UTC] yohgaki@php.net
If you are certain, please provide short and complete module code that leaks 
memory. (i.e. full module code that compiles as module) It should be by using 
ext_skel shell script.
 [2013-08-26 22:55 UTC] yohgaki@php.net
-Status: Open +Status: Feedback
 [2013-08-26 22:55 UTC] yohgaki@php.net
> It should be by using ext_skel shell script.
It should be easy by using ext_skel shell script.
 [2013-08-26 23:01 UTC] johannes@php.net
https://github.com/johannes/php-src/commit/3bfe148c83d6c9b4134ac4fc5f6e0ae36f3f2c42

This might fix your issue. As you won't be telling whether this is our problem I can't properly test it. I'd welcome if you could test it and in future help providing patches.
 [2013-08-26 23:02 UTC] johannes@php.net
meant to write "your problem" :-)
 [2013-08-26 23:02 UTC] yohgaki@php.net
I suspect you have pointer issue. Valgrind does not handle ***(pointer to pointer 
to pointer) well. Check your hash handling code carefully, it may help.
 [2013-08-26 23:07 UTC] rrh at newrelic dot com
-Status: Feedback +Status: Open
 [2013-08-26 23:07 UTC] rrh at newrelic dot com
I will test the patch, and in the future come up with patches for your review.
 [2013-08-26 23:14 UTC] sixd@php.net
-Status: Open +Status: Feedback
 [2013-08-26 23:14 UTC] sixd@php.net
Waiting feedback on the patch
 [2013-08-26 23:15 UTC] johannes@php.net
-Status: Feedback +Status: Open
 [2013-08-26 23:15 UTC] johannes@php.net
A cleaner patch might pass the quiet argument to zend_parse_arg_impl, this would safe the allocation in there.
This also seems to be limited to C and f modifiers which, in PHP itself, aren't used in combination with ZEND_PARSE_PARAMS_QUIET. So for adding a test we might need a deug-build-only functionin zend_builtin_functions.c. This might need coordination with docs and their function detection scripts.

And sorry if I'm a bit harsh, but 99% of the internal API bugs we get are user errors and this bug was sparse on information.
 [2013-08-27 09:42 UTC] nikic@php.net
@johannes: Does this really need a test? The change is rather obvious after all. Introducing debug-only functions for this seems like overkill.
 [2013-08-27 20:06 UTC] aharvey@php.net
With my doc hat on, I'm personally not too concerned if we have a debug build 
only function — we can cross that bridge when we get to it, and I don't think 
anyone relies particularly heavily on the prototype extraction scripts anyway.

With my php-src hat on, would it be better to consider adding a debug extension 
(say ext/debug) that wraps ZE functions where appropriate so we can start writing 
PHPT tests for them, rather than doing this as a one off?
 [2013-08-27 22:44 UTC] johannes@php.net
Adam, well usually we won't need such an test function as usually we only accept things reproducable with core PHP a bug, so this report is no PHP bug. The primary purpose of the debug function here would be to allow verifying this issue was fixed (if rrh confirms this is the actual issue, I might have overseen some other issue).

As I define this as not a PHP bug per se I agreee with Niki that we simply might not add an test to our test suite (currently this would be relevant only in an edge case for a commercial extension, due to the kind of error and PHP's gc also of low severity) but I wanted to discuss the requirements in case somebody picks this bug up.

(and it's not one of, we already have leak() and two or so other debug only functions already)

Anyways, the time spent on discussing this might have been more than needed to fix&test this, so I'll shut up unless anybody wants my review or I have some time&mood while sitting on a machine with a PHP tree. ;-)
 [2021-01-07 13:55 UTC] cmb@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2021-01-07 13:55 UTC] cmb@php.net
Is this still an issue with any of the actively supported PHP
versions[1]?

[1] <https://www.php.net/supported-versions.php>
 [2021-01-17 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Sun Feb 28 11:01:24 2021 UTC