Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of dsaljurator@gmail.com
 designates 74.125.46.153 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=ixozzp5bIKNOvjiFgOqGkhdXUdQ+CPZHx8hURbhbwz8asiND+MKh+mg+U4p/k/y7bb
         gBGm63SUyBrjTe4Bt60SPmNB0kGl1ncp9A6qKHVjFKRuvFSgbBM/J69Ldhi4Rzks/PFp
         079Y1wo8d5LLJVXNxm7UUXU23ZY87iVcIBAkg=
Message-ID: <5bc09a540807132158k34c99420gf63a287c891f4e28@mail.gmail.com>
Date: Mon, 14 Jul 2008 00:58:29 -0400
From: "Adam Prime" <dsaljurator@gmail.com>
To: apreq-dev@httpd.apache.org
Subject: Re: Should we release 2.10?
In-Reply-To: <5bc09a540807132144v7443fb1fr275bee85d4bd8e7b@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <1215737069.4184.24.camel@shrek.rexursive.com>
	 <5bc09a540807131053h78b5a4dcra84a4a99b2dc900b@mail.gmail.com>
	 <1215984314.4184.31.camel@shrek.rexursive.com>
	 <5bc09a540807132142t6eec31b5m6a1931ff167579c@mail.gmail.com>
	 <5bc09a540807132144v7443fb1fr275bee85d4bd8e7b@mail.gmail.com>

On Mon, Jul 14, 2008 at 12:44 AM, Adam Prime <dsaljurator@gmail.com> wrote:
> Apparently i suck at actually sending mail to the list.  I blame gmail.
>
> On Mon, Jul 14, 2008 at 12:42 AM, Adam Prime <dsaljurator@gmail.com> wrote:
>> On Sun, Jul 13, 2008 at 5:25 PM, Bojan Smojver <bojan@rexursive.com> wrote:
>>>
>>> Given it's a request to the whole development group, could you resend to
>>> the list so that other developer see it too?
>>>
>>> It would also be useful to have a backtrace from GDB when this happens.
>>
>> If someone can point my to instructions on how to generate a
>> backtrace, i'll do what i can.  It's not something i have any
>> experience with though.
>>
>> I've fiddled with this a little further.  If you take the following handler:
>>
>> package Kabob::Seg;
>>
>> use Apache2::Request;
>>
>> sub handler {
>>    my $req = Apache2::Request->new($r);
>>    $r->content_type('text/plain');
>>
>>    $r->print('hi');
>>
>>    return Apache2::Const::OK;
>> }
>>
>> 1;
>>
>> and run it under SetHandler perl-script, it will segfault.  If you run
>> it under SetHandler modperl, then you get this in your error_log (and
>> a 500):
>>
>> [Mon Jul 14 00:28:37 2008] [error] [client 127.0.0.1] Apache2->handle
>> called without setting Apache2->request! at
>> /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux/Apache2/Request.pm line
>> 15.\n
>>
>> I have no idea what the difference is.
>>
>> Adam
>>
>

theoretically, this is a backtrace from this.

(gdb) set args -f /www/conf/httpd.conf -DBackEnd -X
(gdb) r
Starting program: /usr/local/prefork/bin/httpd -f /www/conf/httpd.conf
-DBackEnd -X

Program received signal SIGSEGV, Segmentation fault.
0x00002b1e9b043ee7 in XS_APR__Request__Apache2_handle ()
   from /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux/auto/APR/Request/Apache2/Apache2.so
(gdb) bt
#0  0x00002b1e9b043ee7 in XS_APR__Request__Apache2_handle ()
   from /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux/auto/APR/Request/Apache2/Apache2.so
#1  0x00002b1e98ef3ac9 in Perl_pp_entersub () from /usr/lib/libperl.so.1
#2  0x00002b1e98ef226a in Perl_runops_standard () from /usr/lib/libperl.so.1
#3  0x00002b1e98ea2367 in Perl_call_sv () from /usr/lib/libperl.so.1
#4  0x00002b1e98c32710 in modperl_callback () from
/usr/local/prefork/modules/mod_perl.so
#5  0x00002b1e98c32c5d in modperl_callback_run_handlers () from
/usr/local/prefork/modules/mod_perl.so
#6  0x00002b1e98c3300f in modperl_callback_per_dir () from
/usr/local/prefork/modules/mod_perl.so
#7  0x00002b1e98c2f0f0 in modperl_response_handler_run () from
/usr/local/prefork/modules/mod_perl.so
#8  0x00002b1e98c2f26e in modperl_response_handler_cgi () from
/usr/local/prefork/modules/mod_perl.so
#9  0x0000000000437af9 in ap_run_handler (r=0x853788) at config.c:157
#10 0x000000000043abdc in ap_invoke_handler (r=0x853788) at config.c:372
#11 0x000000000044fc38 in ap_process_request (r=0x853788) at http_request.c:258
#12 0x000000000044d0dc in ap_process_http_connection (c=0x84f958) at
http_core.c:190
#13 0x000000000043e791 in ap_run_process_connection (c=0x84f958) at
connection.c:43
#14 0x0000000000461801 in child_main (child_num_arg=<value optimized
out>) at prefork.c:640
#15 0x00000000004619e8 in make_child (s=0x69d150, slot=0) at prefork.c:680
#16 0x0000000000462478 in ap_mpm_run (_pconf=<value optimized out>,
plog=<value optimized out>,
    s=0x69d150) at prefork.c:956
#17 0x0000000000425a37 in main (argc=5, argv=0x7fff1363a5d8) at main.c:730