JDK-8257604: JNI_ArgumentPusherVaArg leaks valist #1565
@tstuefe This change now passes all automated pre-integration checks.
ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.
After integration, the commit message for the final commit will be:
At the time when this comment was updated there had been 1 new commit pushed to the
Please see this link for an up-to-date comparison between the source branch of this pull request and the
➡️ To integrate this PR with the above commit message to the
You can read this for historical copying of va_list args:
But I'm not at all sure that our use of these macros in a RAII helper object is actually valid. From what I've read these macros have to be used in the same function in which the va_list was received.
I'm also not clear why we call va_copy in the first place, as we only need that if the caller also needs to access the va list of arguments. Or perhaps if we need to ensure we actually have something we can pass to another function ... but in that case the va_copy should be in the same function where the va_start is (and the corresponding va_end). (Imagine if args were passed in registers, you'd need to call va_copy to copy them to the stack in the function in which the register still holds the arg.)
E.g. I think this macro:
Though technically we still need the current code and proposed fix as we can't just do a direct assignment in the helper.
Correction: technically va_copy and va_end are supposed to occur in the same function, so we're assuming our RAII object gets inlined if we think we're adhering to that.
Perhaps I'm overthinking all this. It may not be "by the book" but it certainly seems to "work" okay so perhaps best not to rock the boat here. :)
I think the thoughts are valid, I thought it odd too. The usage of va_args is tightly defined.
I also wondered why we copy in the first place, but as I wrote, I was not sure I missed some caller or some way the original ap got used.
"not rocking the boat" - should I just withdraw this patch? Its a small theoretical leak. But I did a quick test on my Ubuntu box, leaking an va_list, and could not see any memory loss. Of course it may still be leaking on other platforms.
IIUC (and at best that is a partial understanding) the allocation of memory by va_start only happens under specific conditions, and I don't know exactly what they are. I tried going to the source:
but that wasn't exactly illuminating without understanding all the other gcc-isms in use. (You may understand better than I.)
I think your fix is harmless, and technically improves the existing code, even if there are potentially other flaws with how we do this. So if you and the other reviewers want to go ahead that seems fine to me.
@tstuefe Since your change was applied there have been 13 commits pushed to the
Your commit was automatically rebased without conflicts.
Pushed as commit ae1eb28.
💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.