I think I am running into the same problem. What I am seeing is that there is an apr_bucket_heap node on the list that has never been completely initialized. When memory is allocated on our platform, the debug code is filling the memory with a specific string. I can tell that the apr_bucket_heap node has never been completely initialized because the actual value of free_func is still set to the original debug filled memory. This obviously causes us to fault. I haven't yet been able to determine where an uninitialized node is being inserted into the list. All I know is that the base contains a non-NULL terminated string, alloc_len contains the length of the string and free_func is uninitialized.
Brad Brad Nicholes Senior Software Engineer Novell, Inc., a leading provider of Net business solutions http://www.novell.com >>> [EMAIL PROTECTED] Friday, March 29, 2002 1:28:03 PM >>> Doug MacEachern wrote: >just looked a bit more, the problem is related to heap buckets and the >free functions. something is broken for sure. i could probably bandaid, >but cliff if you take a look, i'm assuming the right fix would be obvious >to you. > >#1 0x4001cf76 in heap_destroy (data=0x824f758) > at >/home/dougm/apache/farm/src/httpd-2.0-cvs/srclib/apr-util/buckets/apr_buckets_heap.c:74 >74 (*h->free_func)(h->base); >(gdb) p f->free_func >No symbol "f" in current context. >(gdb) p h->free_func >$1 = (void (*)()) 0 > The free_func definitely should be non-null here. It should point to either free() or apr_bucket_free(). Does the rest of *h look valid? (That could help us differentiate memory corruption from some code path that just forgot to set h->free_func.) --Brian
