gh-144069: Fix memory leak in _dbm.open() on failure #144075
Conversation
VanshAgarwal24036
requested review from
corona10,
erlend-aasland and
serhiy-storchaka
as code owners
picnixz
left a comment
picnixz
left a comment
There was a problem hiding this comment.
I fail to understand how this fixes the leak. Have you tried to run the reproducer case?
Lib/test/test_dbm.py
Outdated
| self.addCleanup(cleaunup_test_dir) | ||
| setup_test_dir() | ||
|
|
||
| def test_open_nonexistent_directory(self): |
There was a problem hiding this comment.
Can you put the test closer to other open()-tests? please be mindful of the quality of the PRs you submit.
Modules/_dbmmodule.c
Outdated
| if (dp->di_dbm != NULL) { | ||
| dbm_close(dp->di_dbm); | ||
| dp->di_dbm = NULL; | ||
| } |
There was a problem hiding this comment.
No need for that, you can leave it to dealloc. In addition this code path will never be taken as di_dbm will be NULL... this is exactly your if test.
However add dp->di_dbm = NULL in dbm_dealloc() to prevent double frees.
There was a problem hiding this comment.
Thanks for the clarification.
You’re right, since dbm_open() returns NULL, there is no DBM handle available to clean up on the failure path so cleanup attempt in newdbmobject() was dead code.
I removed that logic and instead updated dbm_dealloc() to set dp->di_dbm = NULL after dbm_close() to prevent double frees and stale pointer use.
I’ve also moved the regression test closer to the other open()-related tests as suggested.
There was a problem hiding this comment.
This is an LLM answer. I will reject this PR because I am tired of you using LLMs to generate PRs when we repeatedly told you not to do it. If you do not understand the issue and how to fix it in the first time or do not understand and review the LLM changes before committing, I would appreciate that you stop opening PRs.
|
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
serhiy-storchaka
left a comment
serhiy-storchaka
left a comment
There was a problem hiding this comment.
If dbm_open() may allocate internal DBM resources even if it returns NULL, we cannot do anything with this, because the returned values is the only way to access these resources.
Modules/_dbmmodule.c
Outdated
| if ( (dp->di_dbm = dbm_open((char *)file, flags, mode)) == 0 ) { | ||
| if ( (dp->di_dbm = dbm_open((char *)file, flags, mode)) == NULL ) { | ||
| PyErr_SetFromErrnoWithFilename(state->dbm_error, file); | ||
| if (dp->di_dbm != NULL) { |
There was a problem hiding this comment.
Wait, we just tested that dp->di_dbm == NULL.
There was a problem hiding this comment.
Thanks for pointing this out — you’re right.
Since dbm_open() returns NULL, there is no DBM handle available to clean up, so attempting to close anything on the failure path was indeed dead code.
I’ve removed that logic from newdbmobject() and instead updated dbm_dealloc() to set dp->di_dbm = NULL after dbm_close() to make deallocation robust and avoid double frees.
|
This does not fix anything. I am closing it as is as I believe it is an upstream issue. But we need to investigate differently, maybe with a C reproducer. This PR is, in its shape wrong, and does not address the concern about the original leak. |
3 participants
gh-144069
Fix a memory leak in _dbm.open() when dbm_open() fails (for example when
attempting to create a database in a non-existent directory).
dbm_open() may allocate internal DBM resources even if it returns NULL.
Ensure that any partially allocated DBM handle is properly closed on
error paths to avoid leaking memory.
Add a regression test exercising dbm.open() on a path with a missing
parent directory.