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.

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.

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.

> It should be by using ext_skel shell script.
It should be easy by using ext_skel shell script.

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.

meant to write "your problem" :-)

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.

I will test the patch, and in the future come up with patches for your review.

Waiting feedback on the patch

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.

@johannes: Does this really need a test? The change is rather obvious after all. Introducing debug-only functions for this seems like overkill.

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?

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. ;-)

Is this still an issue with any of the actively supported PHP
versions[1]?

[1] <https://www.php.net/supported-versions.php>

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.