At 05:44 PM 6/30/2003, Sander Striker wrote: >> From: ranier [mailto:[EMAIL PROTECTED] >> 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 >value.
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. Bill
