[Libreoffice] [PUSHED}[PATCH] leaking connection handles

[Terrence Enger]

Noel,

I am sorry for a long response to an innocent-looking
message, but "a man's gotta do what a man's gotta do".


On Fri, 2011-10-28 at 10:42 +0100, Noel Power wrote:
> On 28/10/11 10:18, Noel Power wrote:
>   just fyi, I did an additional commit to do a minor tweak changing the 
> OSL_TRACE messages into OSL_ENSURE messages. Nothing wrong with the 
> OSL_TRACE, just the OSL_ENSURE does some of the hard work for you ( 
> linenumber & file ) hope I got the logic correct

Yes, the logic looks right to me, as well as being fewer
lines.  Moreover, OSL_ENSURE is effective from dbglevel=1
(and hence is built with ordinary configuration option
--enable-dbgutil), while OSL_TRACE requires at least
dbglevel=2.  All this, I think, favours OSL_ENSURE.

But, on the other hand, ...


On Mon, 2011-10-24 at 23:18 +0200, Stephan Bergmann wrote:
> On 10/24/2011 05:59 PM, Terrence Enger wrote:
> > I shall proceed with that.  And, unless somebody tells me otherwise, I
> > shall indulge myself with OSL_ENSURE() on the return values.
> 
> Note that OSL_ENSURE, OSL_ASSERT, and OSL_FAIL should only be used for 
> logic errors (i.e., the program detects that it contains an error and 
> ends up in a state that "cannot happen"), not for uncommon situations 
> that nevertheless should be handled, like IO errors or malformed user 
> input.  OSL_TRACE, on the other hand, is the tool of choice to document 
> "interesting" events during program execution (which is only evaluated 
> when built with DEBUG=TRUE, however).  --  Even if lots of places in the 
> code base misuse the former for the latter.  Ideally, OSL_ENSURE et al. 
> should directly abort program execution, but we're not there, yet.

As it happens, the leak was indeed the result of a program
error: the program was not calling SQLDisconnect.  But the
ODBC functions represent the whole rest of the world to LO,
and that gives the functions lots of room to go wrong
without implicating LO itself.  Hence my choice of
OSL_TRACE.

I have not addressed "nevertheless should be handled" from
S.B.'s comment: I do not know how to recover from a failed
function call.  OTOH, the leaked handle was evident only
because I happend to be watching drive statistics; later I
noticed failure code 'HY010' in the ODBC trace file.

What do you think?


With thanks for your attention and encouragement,
Terry.