leaked ODBC statement handles
tenger at iseries-guru.com
Mon Jul 16 19:15:02 PDT 2012
I am chasing some "leaked" ODBC statement handles.
I see that ODatabaseMetaDataResultSet.cxx takes care *not* to free a
statement handle which has not been subjected to one of 13 member
functions with names starting "open...". Questions arising ...
(1) Why should this protection be necessary, does anyone know offhand?
It is conceivable that some called function takes responsibility
for freeing the statement handle. But I have looked through the
present class for functions which reference the statement handle
without setting the flag to free the handle, and I see only
function names (I have not looked farther than the names) that
make such transfer of responsibility sound unlikely: 10 functions
with names like "get<sometype>", 6 positioning functions (first,
last, absolute, relative, previous, and next), and "cancel"
(which, IIRC wraps SQLCancel).
(2) Does anyone know offhand of a good reason for a client of the
present class to instantiate it without apparently doing anything
with the statement? The particular leaked statement handles that
I see appear in the ODBC log file only as return values from
(It is just possible that the failure to do anything with the
handle is related to the funny query results that I was looking at
when I noticed the leaked handles.)
(3) Would it be good to report statement handles which "disposing", as
currently written, does not free?
Is there a better place to do this than "disposing"?
I imagine showing a few words and the handle itself. Is there
something else which would be useful and easy to do?
Thank you, all, for your attention.
More information about the LibreOffice