[postgresql-interfaces/psqlodbc] issue #8: Memory leaks detected in psqlodbc library

postgresql-interfaces/psqlodbc GitHub issues and pull requests (mirror)  
help / color / mirror / Atom feed

From: progmachine (@progmachine) <[email protected]>
To: postgresql-interfaces/psqlodbc <[email protected]>
Subject: [postgresql-interfaces/psqlodbc] issue #8: Memory leaks detected in psqlodbc library
Date: Fri, 26 Apr 2024 14:07:23 +0000
Message-ID: <[email protected]> (raw)

Hello, I am working on my C++ applications database connectivity using ODBC. Recently i began running my unit tests with address sanitizer enabled, and LeakSanitizer (used by default with ASAN) detected two points of memory leaks within psqlodbc.

1. The first leak is simple, detected with password field, but i suspect it relates to 3 points of memory leaks with the same principle (ci->password, ci->conn_settings, ci->pqopt): in file dlg_specific.c, function copyConnAttributes, lines 627, 673, 678. If these parameters have been set in data source config, and also provided with connection string, then previous values will be just lost, causing memory leak. It is better to use NULL_THE_NAME macro before assigning new values. I placed macro in correct places, and it fixed this first memory leak point.

2. The second leak is much more complex, leaked objects allocated at parse.c:908, when using SQLDescribeCol function after 'select' SQL-statement, SQLDescribeCol will call getColumnsInfo down the execution code path. This function will allocate COL_INFO objects and place them in ConnectionClass object as columns information cache. Next step to reproduce this bug, is to call 'drop table' SQL-statement in the same connection, it will detect that cache is obsolete and call CC_clear_col_info function on ConnectionClass object, to clear the colinfo cache, but because it is not final destroy, it will see to refcnt field of COL_INFO objects, and leave this objects not destroyed, just detaching them from ConnectionClass object.

The second leak is complex, because leaked objects use reference counting lifetime management, and it is not obvious to me where to look for another points in code, where this lifetime management should be done. May be it's simple refcnt decrement was forgotten in CC_clear_col_info, may be not. For example, StatementClass objects also have references to these COL_INFO objects, but it seems not doing any refcnt lifetime management of COL_INFO objects. If we simply add decrement in CC_clear_col_info function, it will leave zombie references in StatementClass objects. I suspect that this refcnt lifetime management of COL_INFO objects is completely broken...

view thread (31+ 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 #8: Memory leaks detected in psqlodbc library
  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