leaked ODBC statement handles
Lionel Elie Mamane
lionel at mamane.lu
Wed Jul 18 07:25:21 PDT 2012
On Wed, Jul 18, 2012 at 09:55:21AM -0400, Terrence Enger wrote:
> (*) Do you agree that ODatabaseMetaDataResultSet ctor should warn if
> it does not get a statement handle?
It never gets a statement handle as an argument, it allocates it by
calling _pConnection->createStatementHandle(). If the latter fails,
throw an exception, the ODatabaseMetaDataResultSet will be unusable
> On Wed, 2012-07-18 at 05:15 +0200, Lionel Elie Mamane wrote:
>> On Tue, Jul 17, 2012 at 03:46:14PM -0400, Terrence Enger wrote:
>>> On Tue, 2012-07-17 at 19:08 +0200, Lionel Elie Mamane wrote:
>>>> On Mon, Jul 16, 2012 at 10:15:02PM -0400, Terrence Enger wrote:
>>>> (...) I can easily believe the code was leaking statement handles
>>>> in this way even back then (or
>>> Well, I can demonstrate at least a leak. Removing m_bCloseHandle
>>> will of course fix the leak. Still, I wonder if the leak could be
>>> a sign of a bug is client code somewhere. Thoughts?
>> I'm not sure what you mean there.
> Something created a ODatabaseMetaDataResultSet. Presumably the client
> code had some intended purpose for the object. But the statement
> handle appeared in the ODBC log file only in SQLAllocHandle. I
> conclude that the client code did not do very much; as the client code
> did not even free the handle, there is no sign that the client made a
> deliberate decision to abandon its purpose. Hmm, that sounds like it
> could be a bug, or an opportunity for optimization, or an opportunity
> for simplification.
I understand "client code" as "code that creates a
ODatabaseMetaDataResultSet". That code cannot possibly free the
handle, because it cannot possibly know the handle, since it is a
private value of ODatabaseMetaDataResultSet. However, indeed it
creates a ODatabaseMetaDataResultSet and then does nothing with it, so
it could be an opportunity for simplification / optimisation, yes.
I've looked at the first 5 or so ODatabaseMetaDataResultSet ctor calls
in ODatabaseMetaData.cxx, they look like when they don't do anything
with the created ResultSet, it is an error fall-over, to just have an
empty ResultSet to give their caller, which seems reasonable.
But if you find a scenario where there is a more genuine "object
construction not needed here", that would be an interesting place to
look at, yes.
> (*) I confused ODatabaseMetaDataResultSet::dispose, which the dtor
> calls, with ODatabaseMetaDataResultSet::disposing, which frees the
> statement handle. Sheesh, it's not as if the names differed in
> only one letter, or something.
::dispose calls ::disposing; see cppu::OComponentHelper::dispose in
More information about the LibreOffice