leaked ODBC statement handles

[Lionel Elie Mamane]

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
anyway.

> 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
cppuhelper/source/component.cxx

-- 
Lionel