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

Noel Power nopower at suse.com
Fri Oct 28 07:06:15 PDT 2011


On 28/10/11 14:21, Terrence Enger wrote:
> 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".
[...]
>
> 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?
honestly I wouldn't knock myself out worrying about it too much or 
getting into some sort of analysis paralysis trying to decide what to do 
:-) There seems to be many opinions about what should be used where, the 
only real consensus afaik ( if there is even that ) is that we wanted to 
get rid of the old DBG_XXXX macros ( which adds another layer of 
confusion to it all ). Without getting into a religous war about it  I 
personally don't buy that OSL_ENSURE should abort ( I am though a 
believer in that behaviour for for OSL_ASSERT ) Perhaps I am abusing the 
true use for OSL_ENSURE, maybe there is a case for an OSL_WARNING ( but 
do we really need yet another macro ) How likely is this scenario to 
happen?, if it does maybe it does indeed indicate a situation serious 
enough to warrant a big red flag, since this doesn't affect production 
builds no-one is going to die, and if you pardon the pun since 
OSL_ENSURE and friends don't abort neither will Libreoffice ;-)
>
>
> With thanks for your attention and encouragement,
> Terry.
>
>
your welcome

Noel


More information about the LibreOffice mailing list