Skip to content

ext/opcache/jit/zend_jit_trace: fix memory leak in _compile_root_trace() #10146

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jan 9, 2023

Conversation

MaxKellermann
Copy link
Contributor

A copy of this piece of code exists in zend_jit_compile_side_trace(), but there, the leak bug does not exist.

This bug exists since both copies of this piece of code were added in commit 4bf2d09

A copy of this piece of code exists in zend_jit_compile_side_trace(),
but there, the leak bug does not exist.

This bug exists since both copies of this piece of code were added in
commit 4bf2d09
@@ -7099,6 +7099,7 @@ static zend_jit_trace_stop zend_jit_compile_root_trace(zend_jit_trace_rec *trace
if (t->stack_map_size) {
zend_jit_trace_stack *shared_stack_map = (zend_jit_trace_stack*)zend_shared_alloc(t->stack_map_size * sizeof(zend_jit_trace_stack));
if (!shared_stack_map) {
efree(t->stack_map);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should not you set it to NULL after ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not set to NULL in zend_jit_compile_side_trace()... in other code paths, it is however set to NULL. But I guess those could be removed, because nobody cares - if anywould would care, they would be confused as to whether to free it with efree() or not free it because it's already in shared memory. In any case, this code is unclear and confusing.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Upon further investigation, t->stack_map is not accessed again in this function and I believe that t / zend_jit_traces[ZEND_JIT_TRACE_NUM] is considered free and will be initialized when reused, so it's probably safe to not set it to NULL.

On the other hand, the performance implications of setting it to NULL are practically 0 here, and this would reduce the confusion / increase consistency with other branches.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Meanwhile I have written a draft commit (to be submitted as follow-up for #10147) which removes the NULL setters in other branches. I think setting stuff to NULL only adds confusion because it makes the reader believe NULL has a meaning, but here it has none.

@MaxKellermann MaxKellermann mentioned this pull request Dec 21, 2022
@MaxKellermann
Copy link
Contributor Author

@dstogov, please review.

As I mentioned in review comment #10146 (comment) I have a patch for the master branch which removes the unnecessary NULL setters, which I will submit after #10147 is merged.

Copy link
Member

@dstogov dstogov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks right.

@dstogov dstogov merged commit bcc5d26 into php:PHP-8.1 Jan 9, 2023
dstogov added a commit that referenced this pull request Jan 9, 2023
* PHP-8.1:
  ext/opcache/jit/zend_jit_trace: fix memory leak in _compile_root_trace() (#10146)
dstogov added a commit that referenced this pull request Jan 9, 2023
* PHP-8.2:
  ext/opcache/jit/zend_jit_trace: fix memory leak in _compile_root_trace() (#10146)
@MaxKellermann MaxKellermann deleted the compile_root_trace_leak branch January 9, 2023 08:07
MaxKellermann added a commit to CM4all/php-src that referenced this pull request Jan 9, 2023
…e() (php#10146)

A copy of this piece of code exists in zend_jit_compile_side_trace(),
but there, the leak bug does not exist.

This bug exists since both copies of this piece of code were added in
commit 4bf2d09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants