hold original pointer along with aligned to get rid of possibly lost memory leak#1872
Closed
TaeZStkyoht wants to merge 1 commit into
Closed
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
TaeZStkyoht
force-pushed
the
fix_possible_memory_leak_problem_on_entropy_pool
branch
6 times, most recently
from
92322a4 to
23132ed
Compare
Author
|
Why did "Windows MSVC 2022 C++17 Bazel (Optimized)" fail? I cannot see job logs. If I saw it, I would try to fix it. |
…memory leak
Unless pointers have been hold by an object, it's a lost on valgrind's logic. Even we don't free it, we must hold it. In this case, original pointers were not held.
Because gRPC uses this library, grpc usage was creating this memory leak.
before this change:
LEAK SUMMARY:
definitely lost: 0 bytes in 0 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 1,408 bytes in 4 blocks
still reachable: 1,408 bytes in 4 blocks
suppressed: 0 bytes in 0 blocks
after this change:
LEAK SUMMARY:
definitely lost: 0 bytes in 0 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
still reachable: 2,816 bytes in 8 blocks
suppressed: 0 bytes in 0 blocks
Still reachable is not a problem for valgrind.
Signed-off-by: Oguzhan Turk <stkyoht@hotmail.com>
TaeZStkyoht
force-pushed
the
fix_possible_memory_leak_problem_on_entropy_pool
branch
from
23132ed to
b0856c4
Compare
Member
|
Thank you for letting us know about this issue. The failure is an infrastructure flake. While this fix does work, I think using |
copybara-service Bot
pushed a commit
that referenced
this pull request
Apr 21, 2025
for the Randen entropy pool. #1872 reports that since we leak the pointer but no variable holds its address, Valgrind reports a leak. The PR contains a proposed fix, but I believe this is simpler. PiperOrigin-RevId: 749868815 Change-Id: I222fc3202b7a38b8ff960c2398dbf2636e60e490
Member
|
0122890 should fix this issue. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Unless pointers have been hold by an object, it's a lost on valgrind's logic. Even we don't free it, we must hold it. In this case, original pointers were not held.
Because gRPC uses this library, grpc usage was creating this memory leak.
before this change:
LEAK SUMMARY:
definitely lost: 0 bytes in 0 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 1,408 bytes in 4 blocks
still reachable: 1,408 bytes in 4 blocks
suppressed: 0 bytes in 0 blocks
after this change:
LEAK SUMMARY:
definitely lost: 0 bytes in 0 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
still reachable: 2,816 bytes in 8 blocks
suppressed: 0 bytes in 0 blocks
Still reachable is not a problem for valgrind.
Thank you for your contribution to Abseil!
Before submitting this PR, please be sure to read our contributing
guidelines.
If you are a Googler, please also note that it is required that you send us a
Piper CL instead of using the GitHub pull-request process. The code propagation
process will deliver the change to GitHub.