apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Ince" <si...@opendemand.com>
Subject Re: detecting apr memory leaks on windows
Date Tue, 03 Feb 2004 06:47:28 GMT
I was able to partially figure out what was going on by using Purify and
VC++ 6.0.
Everytime I issued  a new apr_pool_create() with a new pool, a corresponding
allocator was being created.
The only I time was completely abled to free all memory, was when I
explicitly destroyed the allocator. For some reason it didn't think I was
the owner of the allocator so it doesn't destroy it until the end with
apr_pool_terminate(). In the following example if you reuse local_pool it
won't create additional allocators but it doesn't destroy the corresponding
allocator with apr_pool_destroy.

    apr_pool_create(&local_pool);
   //The allocator doesn't get destroyed, it doesn't think that the
local_pool is the owner
    apr_pool_destroy(local_pool);

   // it won't create an additional allocator
    apr_pool_create(&local_pool);
   //again the allocator doesn't get destroyed, it doesn't think that the
local_pool is the owner
    apr_pool_destroy(local_pool);

I was using the debug version of the apr.

Example code that freed  all the memory without an explicit call to
apr_terminate.
---------------------------------------------------------------------------
    apr_allocator_create(&local_alloc);
    apr_pool_create_ex(&local_pool,NULL,NULL,local_alloc);

    apr_pool_destroy(local_pool);
    apr_allocator_destroy(local_alloc);
---------------------------------------------------------------------------



Steve
----- Original Message ----- 
From: "Stephen Ince" <since@opendemand.com>
To: "APR Development" <dev@apr.apache.org>; "Rohan Nandode"
<rnandode@yahoo.com>
Sent: Monday, February 02, 2004 7:18 PM
Subject: Re: detecting apr memory leaks on windows


> How can I free the real memory in DEBUG mode?
> I think something is going on with the _DEBUG version of the apr. It is
> somehow keeping track of all memory allocations and then freeing them at
the
> end of apr_terminate or apr_pool_terminate(). I have tried setting
> APR_POOL_DEBUG to 0. When I comment out the apr_pool_terminate() I get no
> memory leaks. In the "Windows output" I know that "{59} normal block" and
> "{58} normal block" are the my local_pool and local_pool2 allocations. I
> think 57 is the allocation for global_pool.
>
> Code
> --------------------------------------------------------------------------
--
> -------------------------------
>    apr_initialize();
>    atexit(NULL);
>    apr_pool_create(&local_pool,NULL);
>    apr_pool_create(&local_pool2,NULL);
>     apr_pool_destroy(local_pool);
>     apr_pool_destroy(local_pool2);
> //    apr_terminate();
> #if defined(_DEBUG) && defined(WIN32)
>    OutputHeading( "Examine outstanding allocations (dump memory leaks)" );
>    _CrtDumpMemoryLeaks( );
> #endif
> --------------------------------------------------------------------------
--
> -------------------------------
>
>
> Windows Output:
> Examine outstanding allocations (dump memory leaks):
> **************************************************************************
> Detected memory leaks!
> Dumping objects ->
> C:\work\flood_openload\apr\memory\unix\apr_pools.c(335) : {59} normal
block
> at 0x0032AB00, 8192 bytes long.
>  Data: <  2   2         > B8 8A 32 00 00 AB 32 00 01 00 00 00 CD CD CD CD
> C:\work\flood_openload\apr\memory\unix\apr_pools.c(335) : {58} normal
block
> at 0x00328AB8, 8192 bytes long.
>  Data: <      2         > 00 00 00 00 B8 8A 32 00 01 00 00 00 CD CD CD CD
> C:\work\flood_openload\apr\memory\unix\apr_pools.c(335) : {57} normal
block
> at 0x00326A70, 8192 bytes long.
>  Data: <pj2 pj2         > 70 6A 32 00 70 6A 32 00 01 00 00 00 CD CD CD CD
> C:\work\flood_openload\apr\memory\unix\apr_pools.c(335) : {56} normal
block
> at 0x00324A28, 8192 bytes long.
>  Data: <(J2 (J2         > 28 4A 32 00 28 4A 32 00 01 00 00 00 CD CD CD CD
> C:\work\flood_openload\apr\memory\unix\apr_pools.c(132) : {55} normal
block
> at 0x00322DF8, 104 bytes long.
>  Data: <            xJ2 > 01 00 00 00 00 00 00 00 FE FF FF FF 78 4A 32 00
> Object dump complete.
> --------------------------------------------------------------------------
--
> ---------------------------------------
> ----- Original Message ----- 
> From: "Rohan Nandode" <rnandode@yahoo.com>
> To: "Stephen Ince" <since@opendemand.com>; "APR Development"
> <dev@apr.apache.org>
> Sent: Monday, February 02, 2004 7:36 AM
> Subject: Re: detecting apr memory leaks on windows
>
>
> >
> > When you initialize APR library, a global pool is
> > created for APR library. This pool is a parent of all
> > pools that you create without specifying any parent
> > pool, as you have done below. All such pools share a
> > common allocator from which they allocate the required
> > memory.
> >
> > This allocator is destroyed and freed during
> > apr_terminate. (or you can call apr_pool_terminate())
> >
> > Hence you are seeing the memory leak when you comment
> > out apr_terminate().
> > For pools for which you have specified the parent,
> > their memory will be freed when the parent pool is
> > destroyed.
> >
> > HTH,
> > Rohan
> >
> > --- Stephen Ince <since@opendemand.com> wrote:
> > > When does the real memory from a pool actually get
> > > destroyed. I am using VC++ 6.0 to try and debug
> > > memory leaks. I thought that apr_pool_destroy
> > > destroys the real memory. If I uncomment the line
> > > apr_terminate(), all the memory is cleaned up. How
> > > can I immediately destroy the real memory from a top
> > > level pool?
> > >
> > > I have the following code:
> > >
> > > int main(int argc, char** argv)
> > > {
> > >     apr_pool_t *local_pool;
> > >     apr_initialize();
> > >     apr_pool_create(&local_pool, NULL);
> > >     apr_pool_destroy(local_pool);
> > > // apr_terminate();
> > > #if defined(_DEBUG) && defined(WIN32)
> > >    OutputHeading( "Examine outstanding allocations
> > > (dump memory leaks)" );
> > >    _CrtDumpMemoryLeaks( );
> > >    OutputHeading( "Program exits without freeing a
> > > memory block" );
> > >    SET_CRT_DEBUG_FIELD( _CRTDBG_LEAK_CHECK_DF );
> > > #endif
> > >     return EXIT_SUCCESS;
> > > }
> > >
> > >
> > >
> > >
> > > Steve
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! SiteBuilder - Free web site building tool. Try it!
> > http://webhosting.yahoo.com/ps/sb/
> >
>
>


Mime
View raw message