Re: bucket free list breakage (was Re: cvs commit:httpd-2.0/server/mpm/workerworker.c)
On Fri, 29 Mar 2002, Cliff Woolley wrote: > Yes. The SSLProxyEngine on directive is missing from the config file. I > added it manually and it works. I expect something like this would do the > trick: oh duh, i had made the change but didn't commit. glad to hear it works.
Re: bucket free list breakage (was Re: cvs commit:httpd-2.0/server/mpm/workerworker.c)
On Fri, 29 Mar 2002, Doug MacEachern wrote: > > PS: I now pass all httpd-test tests except these: > > http.t fails for me too, has for a while. > proxy.t passes for me, but this is new stuff. anything interesting in the > error_log? Yes. The SSLProxyEngine on directive is missing from the config file. I added it manually and it works. I expect something like this would do the trick: Index: proxyssl.conf.in === RCS file: /home/cvs/httpd-test/perl-framework/t/conf/ssl/proxyssl.conf.in,v retrieving revision 1.1 diff -u -d -r1.1 proxyssl.conf.in --- proxyssl.conf.in29 Mar 2002 17:12:19 - 1.1 +++ proxyssl.conf.in29 Mar 2002 23:54:15 - @@ -9,6 +9,9 @@ ProxyPass/ https://@proxyssl_url@/ ProxyPassReverse / https://@proxyssl_url@/ + +SSLProxyEngine on + But does it need some crud in there too? --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: bucket free list breakage (was Re: cvs commit:httpd-2.0/server/mpm/workerworker.c)
On Fri, 29 Mar 2002, Cliff Woolley wrote: > Okay, fixed. excellent, thanks. > PS: I now pass all httpd-test tests except these: http.t fails for me too, has for a while. proxy.t passes for me, but this is new stuff. anything interesting in the error_log?
Re: bucket free list breakage (was Re: cvs commit:httpd-2.0/server/mpm/workerworker.c)
On Fri, 29 Mar 2002, Cliff Woolley wrote: > > 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. Okay, fixed. We were forgetting to set free_func in the pool buckets case. pool_make subsumes the logic of heap_make, so anything you do in heap_make must be done in pool_make as well. Unfortunately pool_make can't just call heap_make because heap_make allocates too little space for the bucket type-specific data structure as far as pool buckets are concerned. I added a comment on heap_make warning of this for the future. Thanks for catching this! --Cliff PS: I now pass all httpd-test tests except these: Failed Test Status Wstat Total Fail Failed List of Failed ssl/http.t 11 100.00% 1 ssl/proxy.t11 100.00% 1 ssl/http.t has failed forever, and I don't know what's up with ssl/proxy.t, since you just added that today. Will check on it. -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: bucket free list breakage (was Re: cvs commit:httpd-2.0/server/mpm/workerworker.c)
On Fri, 29 Mar 2002, Brad Nicholes wrote: > 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. I'm looking into this right now. I'll report back ASAP. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: bucket free list breakage (was Re: cvs commit:httpd-2.0/server/mpm/workerworker.c)
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
