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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
