>> that may be the case, however when you don't enable POOL_DEBUG, >> it doesn't _do_ anything! the guarantees, esp. if the behaviour >> of the program is affected _by_ enabling POOL_DEBUG, are almost >> worthless.
Actually, the implementation of the memory system code depends heavily on asserts and some debug code is only executed when APR_MEMORY_SYSTEM_DEBUG is defined. Maybe APR_MEMORY_SYSTEM_DEBUG should just be set when normal debugging is enabled? > They only do one thing -- they tell the maintainer that someone just > committed something rather clueless. Dean (and myself when I had time) > used to compile httpd 1.3 with ALLOC_DEBUG and POOL_DEBUG on all the time > in order to catch places where modules were combining memory from multiple > pools. It is not intended to be a run-time check for deployed systems > because that would add pointless overhead (there is no recovery > path anyway). > It may not work right now in 2.0, since I recall someone monkeying with > the code because it wasn't thread-safe. > > You will need the same kind of thing for stackable memory systems > -- there > needs to be a way for a developer to ensure that data allocated within a > data structure is as long-lived as the data structure itself. Could you expand on this? Ie, give a small example (I probably have in my head what you mean, but I want to make sure)? > .....Roy Sander
