Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (hermes.apache.org: domain of gcaa-apreq-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
Mail-Followup-To: apreq-dev@httpd.apache.org
To: apreq-dev@httpd.apache.org
From: Joe Schaefer <joe+gmane@sunstarsys.com>
Subject: Re: [apreq2] Crash during env test startup on Win32
Date: Tue, 21 Dec 2004 20:01:26 -0500
Lines: 40
Message-ID: <87vfavgn89.fsf@gemini.sunstarsys.com>
References: <41C8B2E3.9000100@gmx.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Mail-Copies-To: never
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux)
Cancel-Lock: sha1:6mHhCmAKHzhtu/ySmHUUbzwjLLo=
Sender: news <news@sea.gmane.org>


Markus Wichitill <mawic@gmx.de> writes:

> apreq_filter_make_context(ap_filter_t * 0x0090abd8) line 367 + 3 bytes
> apreq_filter(ap_filter_t * 0x0090abd8, apr_bucket_brigade * 0x0090ad80, int 0,
> int 0, __int64 8192) line 571 + 9 bytes
> ap_get_brigade(ap_filter_t * 0x0090abd8, apr_bucket_brigade * 0x0090ad80, int
> 0, int 0, __int64 8192) line 475 + 32 bytes
> ap_discard_request_body(request_rec * 0x00909158) line 1959 + 30 bytes
> default_handler(request_rec * 0x00909158) line 3504 + 9 bytes

Assuming this is the opening A-T ping:

         GET /index.html

The relevant server-config item is:

    t/conf/httpd.conf:    AddOutputFilter APREQ_OUTPUT_FILTER html


So we have an output filter which has asked for apreq 
during its filter-init.  The backtrace here is the 
default handler trying to discard the (non-existent) 
body before serving up its response, but 
apreq_filter_make_context is choking.

>   make_new_context:
>      if (req != NULL && f == r->input_filters) {
>          if (req->body_status != APR_EINIT) {
> ->          req->body = NULL;

If the trace is to be believed, your "req" pointer is certainly bogus.
The only recent change I can think of which *might* be relevant
is the addition of a bucket_alloc function pointer to apreq_env_t.
Somehow your local mod_apreq might be linking against another libapreq2,
which could explain the req corruption.  If that cannot be the case,
we'll have to wait for Randy to weigh in.

-- 
Joe Schaefer