apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@xbc.nu>
Subject Re: apr leak windows
Date Thu, 12 Nov 2009 16:51:46 GMT
Alex Afrasinei wrote:
> Hello,
> Used BoundsChecker tool and it reports some leaks/errors on windows in apr.
> Function CommandLineToArgvW in apr_app_initialize(misc/win32/start.c).
> Some macros are used for this (APR_DECLARE_LATE_DLL_FUNC) and
> is called apr_load_dll_func (misc/win32/misc.c) which calls LoadLibrary.
> Seems handle for LoadLibrary is never freed with FreeLibrary so a
> resource leak is reported when exiting program.

This is not really a problem. It's a little bit messy, but not a "leak"
since the size of the allocated resources is constant throughtout the
lifetime of the problem. The OS will properly clean up the DLL
references when the program exits.

> Though the handle is stored in a static array in misc.c (static
> HMODULE lateDllHandle[DLL_defined])
> To fix this i made a function which calls FreeLibrary on the handle in
> lateDllHandle array , and call it in apr_terminate.

That looks like a good solution on the face of it, but I know from
personal experience that it can lead to horrible bugs. The failure case
is when some pool cleanup handler calls a function from a dynamically
loaded library, but then apr_terminate unloads the library before it
calls that cleanup handler. Such out-of-order bugs can be avoided on the
application level, but not easily, if at all, in APR itself. So it's
better to "leak" a few DLL handles than to make life miserably horrible
for every APR user who uses DSOs.

> Also for same call to CommandLineToArgvW (misc.c)
>  wstrs = CommandLineToArgvW(sysstr, &wstrc);
>             if (wstrs) {
>                 *argc = apr_wastrtoastr(argv, wstrs, wstrc);
>                 GlobalFree(wstrs);
>             }
> Allocation Conflict: Attempting to call GlobalFree on 0x017BE080;
> pointer was allocated by LocalAlloc.
> A memory block was allocated with one type of allocator, and
> deallocated with an incompatible deallocator.
> msdn entry for CommandLineToArgvW says LocalFree should be used.
> I dont know if this is a real problem but calling LocalFree instead of
> GlobalFree fix the reported error.

This indeed appears to be a bug. Thanks for finding it!

-- Brane

View raw message