postgresql-interfaces/psqlodbc GitHub issues and pull requests (mirror)
help / color / mirror / Atom feedFrom: cipriani-ivan (@cipriani-ivan) <[email protected]>
To: postgresql-interfaces/psqlodbc <[email protected]>
Subject: [postgresql-interfaces/psqlodbc] issue #189: Possible double-free / heap corruption in psqlODBC during SQLDisconnect cleanup
Date: Thu, 21 May 2026 12:35:22 +0000
Message-ID: <[email protected]> (raw)
Dear psqlODBC maintainers,
I would like to report a potential memory corruption issue in the PostgreSQL ODBC driver and ask whether this is a known or tracked problem.
Summary
We are observing repeatable heap corruption (0xC0000374) in a .NET application using:
PostgreSQL: 17.9
psqlODBC: 17.0.0.4
Windows: x64
Driver: PostgreSQL Unicode (x64)
The failure occurs during connection teardown after a failed connection.
Observed behavior
With Application Verifier + Page Heap, the crash consistently reports:
HEAP_CORRUPTION_ACTIONABLE_BlockNotBusy_DOUBLE_FREE
Stack trace
Below is the stack trace captured in WinDbg:
ucrtbase!free_base
psqlodbc35w!SC_clear_error
psqlodbc35w!PGAPI_FreeStmt
psqlodbc35w!SQLFreeStmt
odbc32!SQLDisconnect
System.Data.Odbc.OdbcConnection.Close()
This suggests a double free during statement/connection cleanup, likely in an error path.
Reproduction scenario
The issue appears under the following conditions:
Connection attempt fails (e.g. SQLSTATE 08S01, connection down)
Application immediately disposes the connection
Cleanup invokes SQLDisconnect / SQLFreeStmt
Occurs more frequently under:
Release builds
Parallel workloads
Forced cleanup paths
Analysis / suspicion
Multiple cleanup layers (SC_clear_error, PGAPI_FreeStmt) appear to release overlapping resources
The issue occurs in a failure path (connection already down)
Recent release notes do not indicate changes in this cleanup logic
Similar memory-safety fixes exist historically but not in this code path
Questions
Is this behavior a known issue in current psqlODBC versions?
Is there ongoing work related to cleanup safety in error paths?
Are there recommended usage constraints (threading / disposal patterns) to avoid this?
Context
This occurs in a modern multithreaded .NET application, where:
Failed connections are disposed immediately
Cleanup may occur under concurrency
Robust handling of failure paths is required
We understand the complexity of ODBC lifecycle semantics, but this appears to expose a double-free condition under certain cleanup scenarios.
Thank you for your time and for maintaining psqlODBC.
Best regards,
Ivan Cipriani
view thread (6+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: github://postgresql-interfaces/psqlodbc
Cc: [email protected], [email protected]
Subject: Re: [postgresql-interfaces/psqlodbc] issue #189: Possible double-free / heap corruption in psqlODBC during SQLDisconnect cleanup
In-Reply-To: <<[email protected]>>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox