RE: cvs commit: apr/memory/unix TODO

[Sander Striker <st...@samba-tng.org>]

> Subject: cvs commit: apr/memory/unix TODO
> dreid       01/05/29 16:48:35
> 
>   Added:       memory/unix TODO
>   Log:
>   Add a TODO for the memory stuff.

[...]

>   - given the problems that can occur when trying to find 
>     alloc/free problems we should probably have a special debug
>     memory system that records everything it does and any
>     other information we think is useful.

Getting info like the line the call was made from will be a bit
tricky to say the least. There was some discussion on the list
about it, but no resolution yet.
   
>   - in addition to the debugging system, we need to look at
>     methods of checking memory allocations to ensure we're
>     behaving when we have the ASSERT_MEMORY flag turned on.
>     The pools in 1.3 had code from dean and Roy, Greg has added
>     some special stuff for pools under Linux on 2.0, so we just
>     need some ideas

Under *nix some mprotect() trickery could do the trick, under
windows there is VirtualProtect(). Thoughts?

Sander

Re: cvs commit: apr/memory/unix TODO

[David Reid <dr...@jetnet.co.uk>]

> >   - given the problems that can occur when trying to find 
> >     alloc/free problems we should probably have a special debug
> >     memory system that records everything it does and any
> >     other information we think is useful.
> 
> Getting info like the line the call was made from will be a bit
> tricky to say the least. There was some discussion on the list
> about it, but no resolution yet.

I have some thgoughts and will be looking at this.  Patience is a virtue :)

>    
> >   - in addition to the debugging system, we need to look at
> >     methods of checking memory allocations to ensure we're
> >     behaving when we have the ASSERT_MEMORY flag turned on.
> >     The pools in 1.3 had code from dean and Roy, Greg has added
> >     some special stuff for pools under Linux on 2.0, so we just
> >     need some ideas
> 
> Under *nix some mprotect() trickery could do the trick, under
> windows there is VirtualProtect(). Thoughts?

There are lots of things we can do :)

david

Re: cvs commit: apr/memory/unix TODO

[Justin Erenkrantz <je...@ebuilt.com>]

On Wed, May 30, 2001 at 11:25:32AM +0200, Sander Striker wrote:
> Getting info like the line the call was made from will be a bit
> tricky to say the least. There was some discussion on the list
> about it, but no resolution yet.

I thought we said that the call stack is better for this purpose.
We don't need the line the call was made with the __FILE__ and 
__LINE__ macros.  And, if you aren't doing interactive debugging, 
you can always have apr dump core if you want to see how you got 
there.  You'll also get more info with the core file anyway.  

Maybe I'm wrong, but that is how I remember the previous 
conversation.  -- justin