Set func pointer to null in Closure __invoke #12275
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I've written the comment as if it's happened and been agreed to, but I want to have a little bit of discussion here. The only reason I can think of for this to not be done unconditionally, is something like this:
Detect detect use-after-frees in this code in non-debug asan builds, and avoid the absolutely minuscule cost of setting it to null in release builds. This means that we would want to be sure that literally everything in the engine and the entire ecosystem should know this is an invalid pointer even though it's not null.
For instance:
That seems like a stretch. Of course, I did not know this and a customer hit this in production, causing a crash.
I think it would be best to set this to null, rather than requiring them to do something like:
Note that observers avoid this because the end observer is skipped in cases like this. Maybe @bwoebi can provide a more detailed explanation there.
Also note that even if we set this to
null
, there is still a potential gotcha here. I don't know how many people would expectexecute_data->func
to be null after the call when it wasn't before. The profiling extension I work on would have been okay, but I think this is already a decently big gotcha, no need to make it doubly-sharp by leaving an invalid, non-null pointer on theexecute_data
.