apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject RE: [PACTH] debug ideas for memory allocation
Date Wed, 09 Jul 2003 04:24:18 GMT
At 05:44 PM 6/30/2003, Sander Striker wrote:
>> From: ranier [mailto:ranier@cultura.com.br]
>> Sent: Monday, June 30, 2003 5:28 AM
>> I read a Steve Maguire book named "Guia Microsoft para o desenvolvimento 
>> de programas
>> sem erros" [ironic not?] and add some ideas for debugging memory 
>> allocation in apr_pool.c.
>> 1. Memory not initialized or freed is trash, on debug force this!
>> 2. Use intensive of the function "assert" on debug development.
>Using pools debug mode in combination with tools like valgrind
>have worked wonders.  I personally don't think this will add extra

Actually, we had implemented a single-use mode that was lost in recent
APR pool redesigns, as well as a pool-lock mode that would ensure any
'read only' memory wasn't corrupted.  This should be reimplemented.

Our trick was to malloc from mmap sections that would be locked as
no-read, no-write after destruction.  Any attempt to use that memory
later would ensure a segv.

This was even simpler for Win32, since we can allocate vm pages,
then free but not release the memory.

And the write protect feature allowed us to test that 'thread-shared,
const' memory was never modified.  httpd was calling the pool_lock
API on the config pool once the configuration was completed, before
we spawned threads.  If any thread touched this memory, bang.

Of course that pool was unlocked on shutdown.

Both of these methods are very vm-page intensive, but effective
for short tests and finding many obvious bugs.  I would love to find
time this month to revisit those features, but would probably ask for
linux/solaris help to implement them cleanly on those platforms without
the overhead of using mmap regions.


View raw message