You are viewing a plain text version of this content. The canonical link for it is here.

Posted to commits@apr.apache.org by dr...@apache.org on 2001/05/30 01:48:35 UTC

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.
  
  Revision  Changes    Path
  1.1                  apr/memory/unix/TODO
  
  Index: TODO
  ===================================================================
  This is just a small list of things yet to be done, or things
  that we may want/need to consider.  I haven't put it in the
  STATUS file for APR as none of these can be considered
  showstoppers for the time being.
  david - 28 May 2001
  
  - we need to add dynamic loading ability for memory
    systems.  As to how it should be done this needs to be
    looked at.  Some known issues include 
      o differing arguments for create functions
  
    Just to clarify why this will be very cool if we can get
    it working, we give the user the ability to use 3rd party modules
    that can actually have almost total control over how the
    memory is allocated. Not sure I know of other libraries where
    this is possible.
  
  - 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.
  
  - 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

Re: cvs commit: apr/memory/unix TODO

Posted by 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

Re: cvs commit: apr/memory/unix TODO

Posted by 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

Posted by 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