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.

Sign up for GitHub

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
Merged

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

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions ext/opcache/jit/zend_jit_trace.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.

ret = ZEND_JIT_TRACE_STOP_NO_SHM;
goto exit;
}
Expand Down