You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by ranier <ra...@cultura.com.br> on 2003/06/30 05:27:53 UTC
[PACTH] debug ideas for memory allocation
Hi,
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.
I wait to be helping.
Thanks in advance.
Ranier Vilela
RC Software
ps. Resubmit, forgot the apr_pools.h!
RE: [PACTH] debug ideas for memory allocation
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
>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
Re: [PACTH] debug ideas for memory allocation
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Jul 03, 2003 at 01:06:23AM +0200, Sander Striker wrote:
>...
> +++ srclib/apr/memory/unix/apr_pools.c 2 Jul 2003 23:01:10 -0000
> @@ -1212,6 +1212,10 @@
> if (pool == global_pool || global_pool == NULL)
> return;
>
> + /* A NULL pool?! */
> + if (!pool)
> + abort();
I'd suggest moving this above the global_pool check. Otherwise, the
global_pool test could throw you out of the function before you detect a
NULL pool.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
RE: [PACTH] debug ideas for memory allocation
Posted by Sander Striker <st...@apache.org>.
> From: ranier [mailto:ranier@cultura.com.br]
> Sent: Monday, June 30, 2003 7:29 PM
> Sander Striker wrote:
>
>> Using pools debug mode in combination with tools like valgrind
>> have worked wonders. I personally don't think this will add extra
>> value.
>
> Why not use all weapons? Bugs exist and will be found, but not in
> automatic way!
> What I am considering is to add tools to find bugs in automatic way.
>
> The biggest utility in destroying the memory set free, it is not to lose
> time in finding errors in structures apparently perfect, but obviously
> garbage!
The third party tools available to detect this are so much better than
we can provide and are willing to maintain. There's electric fence,
valgrind, purify and a bunch of others all with there own strength
and level of complexity. Using the memset trick doesn't tell you
_where_ things went wrong, only that you are looking at free'd memory.
As for the asserts, you can replace all of them by adding a few lines
to apr_pool_check_integrity:
Index: srclib/apr/memory/unix/apr_pools.c
===================================================================
RCS file: /home/cvs/apr/memory/unix/apr_pools.c,v
retrieving revision 1.196
diff -u -r1.196 apr_pools.c
--- srclib/apr/memory/unix/apr_pools.c 28 May 2003 04:39:42 -0000 1.196
+++ srclib/apr/memory/unix/apr_pools.c 2 Jul 2003 23:01:10 -0000
@@ -1212,6 +1212,10 @@
if (pool == global_pool || global_pool == NULL)
return;
+ /* A NULL pool?! */
+ if (!pool)
+ abort();
+
/* Lifetime
* This basically checks to see if the pool being used is still
* a relative to the global pool. If not it was previously
Sander
Re: [PACTH] debug ideas for memory allocation
Posted by ranier <ra...@cultura.com.br>.
Sander Striker wrote:
>Using pools debug mode in combination with tools like valgrind
>have worked wonders. I personally don't think this will add extra
>value.
>
>
Why not use all weapons? Bugs exist and will be found, but not in
automatic way!
What I am considering is to add tools to find bugs in automatic way.
The biggest utility in destroying the memory set free, it is not to lose
time in finding errors in structures
pparently perfect, but obviously garbage!
Ranier Vilela
RC Software
RE: [PACTH] debug ideas for memory allocation
Posted by Sander Striker <st...@apache.org>.
> 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
value.
Sander