Fix the memory leaks observed by ASan testing#4690
Merged
tanscorpio7 merged 1 commit intobabelfish-for-postgresql:BABEL_5_X_DEVfrom Apr 2, 2026
Merged
Fix the memory leaks observed by ASan testing#4690tanscorpio7 merged 1 commit intobabelfish-for-postgresql:BABEL_5_X_DEVfrom
tanscorpio7 merged 1 commit intobabelfish-for-postgresql:BABEL_5_X_DEVfrom
Conversation
Signed-off-by: Harsh Dubey <harshdu@amazon.com>
tanscorpio7
approved these changes
Apr 2, 2026
dab7675
into
babelfish-for-postgresql:BABEL_5_X_DEV
47 checks passed
harshdubey166
added a commit
to amazon-aurora/babelfish_extensions
that referenced
this pull request
Apr 2, 2026
This commit fixes memory leaks observed when testing with ASan 1. In the function TdsSendRowDescription() , strdup() allocates memory using the system's malloc(), which is completely outside PostgreSQL's memory management. This means the string stored in relMetaDataInfo->partName[1] lives in malloc-heap, not in any PostgreSQL memory context. By using pstrdup() , it allocates using palloc() inside the current memory context (MessageContext), so it's properly tracked and will be freed when that context is destroyed. 2. Similarly in the function rewrite_if_condition(), strdup uses malloc which is invisible to PostgreSQL's memory management while pstrdup allocates in the current memory context, which gets cleaned up automatically. Task: BABEL-6422 Authored by : harshdu@amazon.com
1 task
harshdubey166
added a commit
to amazon-aurora/babelfish_extensions
that referenced
this pull request
Apr 2, 2026
This commit fixes memory leaks observed when testing with ASan 1. In the function TdsSendRowDescription() , strdup() allocates memory using the system's malloc(), which is completely outside PostgreSQL's memory management. This means the string stored in relMetaDataInfo->partName[1] lives in malloc-heap, not in any PostgreSQL memory context. By using pstrdup() , it allocates using palloc() inside the current memory context (MessageContext), so it's properly tracked and will be freed when that context is destroyed. 2. Similarly in the function rewrite_if_condition(), strdup uses malloc which is invisible to PostgreSQL's memory management while pstrdup allocates in the current memory context, which gets cleaned up automatically. Task: BABEL-6422 Authored by : harshdu@amazon.com
1 task
tanscorpio7
pushed a commit
that referenced
this pull request
Apr 2, 2026
This commit fixes memory leaks observed when testing with ASan 1. In the function TdsSendRowDescription() , strdup() allocates memory using the system's malloc(), which is completely outside PostgreSQL's memory management. This means the string stored in relMetaDataInfo->partName[1] lives in malloc-heap, not in any PostgreSQL memory context. By using pstrdup() , it allocates using palloc() inside the current memory context (MessageContext), so it's properly tracked and will be freed when that context is destroyed. 2. Similarly in the function rewrite_if_condition(), strdup uses malloc which is invisible to PostgreSQL's memory management while pstrdup allocates in the current memory context, which gets cleaned up automatically. Task: BABEL-6422 Authored by : harshdu@amazon.com
tanscorpio7
pushed a commit
that referenced
this pull request
Apr 2, 2026
This commit fixes memory leaks observed when testing with ASan 1. In the function TdsSendRowDescription() , strdup() allocates memory using the system's malloc(), which is completely outside PostgreSQL's memory management. This means the string stored in relMetaDataInfo->partName[1] lives in malloc-heap, not in any PostgreSQL memory context. By using pstrdup() , it allocates using palloc() inside the current memory context (MessageContext), so it's properly tracked and will be freed when that context is destroyed. 2. Similarly in the function rewrite_if_condition(), strdup uses malloc which is invisible to PostgreSQL's memory management while pstrdup allocates in the current memory context, which gets cleaned up automatically. Task: BABEL-6422 Authored by : harshdu@amazon.com
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
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.
Description
This PR fixes the memory leaks observed when testing with ASan.
In the function PrepareRowDescription() , strdup() allocates memory using the system's malloc(), which is completely outside PostgreSQL's memory management. This means the string stored in relMetaDataInfo->partName[1] lives in malloc-heap, not in any PostgreSQL memory context.
By using pstrdup() , it allocates using palloc() inside the current memory context (MessageContext), so it's properly tracked and will be freed when that context is destroyed.
Similarly in the function rewrite_if_condition(), strdup uses malloc which is invisible to PostgreSQL's memory management while pstrdup allocates in the current memory context, which gets cleaned up automatically.
Issues Resolved
[BABEL-6422]
Authored by : harshdu@amazon.com
Signed-off by : harshdu@amazon.com
Check List
By submitting this pull request, I confirm that my contribution is under the terms of the Apache 2.0 and PostgreSQL licenses, and grant any person obtaining a copy of the contribution permission to relicense all or a portion of my contribution to the PostgreSQL License solely to contribute all or a portion of my contribution to the PostgreSQL open source project.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.