[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