You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Geoffrey Young <ge...@modperlcookbook.org> on 2003/08/25 17:33:17 UTC
Re: SubRequest in Filter MP2 [QUESTION]
>> my $rr = $f->r->lookup_uri("subrequest.txt");
>> #$rr->run;
> For some reason, the server segfaults when the above code is run (with
> the $rr->run line present)
does anything change if you use
$rr = $f->$r->lookup_uri("subrequest.txt", $f->next);
?
--Geoff
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
[...]
> as I said, nowhere in any of the module shipped with core do I find
> logic like this - mod_include and mod_cgi both seem to call
> ap_run_sub_req without flushing the main data stream (though
> mod_include does split the stream and send the data _prior to the tag_
> off). I don't see why mod_perl needs to behave differently in this
> respect, but if flushing is required for other reasons I can't see,
> making it a tacit part of $sub->run seems the wrong solution since it
> goes against the intent of output filters.
but that's how it works in mp1, no? Are you required to flush any data before
issuing a subrequest? If I remember correctly you aren't.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
[...]
> as I said, nowhere in any of the module shipped with core do I find
> logic like this - mod_include and mod_cgi both seem to call
> ap_run_sub_req without flushing the main data stream (though
> mod_include does split the stream and send the data _prior to the tag_
> off). I don't see why mod_perl needs to behave differently in this
> respect, but if flushing is required for other reasons I can't see,
> making it a tacit part of $sub->run seems the wrong solution since it
> goes against the intent of output filters.
but that's how it works in mp1, no? Are you required to flush any data before
issuing a subrequest? If I remember correctly you aren't.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: SubRequest in Filter MP2 [QUESTION]
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> however, removing that logic causes api/lookup_uri2.t to fail, but I
>> suspect this is an issue with puts() rather than the subrequest
>> mechanism - changing puts() to print() makes everything work just
>> fine. does puts() write directly to the wire, bypassing filters?
>
>
> Sorry, but that's cheating ;)
>
> rputs() never flushes data,
> print() flushes if $| == 1;
ah, ok, that's the difference.
>
> So there is no problem with the r->main logic in mpxs_ap_run_sub_req,
> it's there for exactly this reason.
no, there is definitely something wrong. someplace :)
if I'm in a filter and call sub->run (which is what mod_include essentially
does), mod_perl is silently passing along the data I'm in the middle of
filtering. so, if the filter sees
data<tag>data
and wants to substitute something for <tag> via a subrequest, it won't work
- mpxs_ap_run_sub_req is flushing <tag> along before the filter gets the
chance to decide about the data.
as I said, nowhere in any of the module shipped with core do I find logic
like this - mod_include and mod_cgi both seem to call ap_run_sub_req without
flushing the main data stream (though mod_include does split the stream
and send the data _prior to the tag_ off). I don't see why mod_perl needs
to behave differently in this respect, but if flushing is required for other
reasons I can't see, making it a tacit part of $sub->run seems the wrong
solution since it goes against the intent of output filters.
> and you forgot to add to the patch a new file
> #t/htdocs/filter/subrequest.txt
> core subrequest
yes, sorry.
> or even better:
>
> out_str_subreq_default
> out_str_subreq_modperl
>
> since these correspond to the SetHandler settings.
will do.
--Geoff
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> however, removing that logic causes api/lookup_uri2.t to fail, but I
>> suspect this is an issue with puts() rather than the subrequest
>> mechanism - changing puts() to print() makes everything work just
>> fine. does puts() write directly to the wire, bypassing filters?
>
>
> Sorry, but that's cheating ;)
>
> rputs() never flushes data,
> print() flushes if $| == 1;
ah, ok, that's the difference.
>
> So there is no problem with the r->main logic in mpxs_ap_run_sub_req,
> it's there for exactly this reason.
no, there is definitely something wrong. someplace :)
if I'm in a filter and call sub->run (which is what mod_include essentially
does), mod_perl is silently passing along the data I'm in the middle of
filtering. so, if the filter sees
data<tag>data
and wants to substitute something for <tag> via a subrequest, it won't work
- mpxs_ap_run_sub_req is flushing <tag> along before the filter gets the
chance to decide about the data.
as I said, nowhere in any of the module shipped with core do I find logic
like this - mod_include and mod_cgi both seem to call ap_run_sub_req without
flushing the main data stream (though mod_include does split the stream
and send the data _prior to the tag_ off). I don't see why mod_perl needs
to behave differently in this respect, but if flushing is required for other
reasons I can't see, making it a tacit part of $sub->run seems the wrong
solution since it goes against the intent of output filters.
> and you forgot to add to the patch a new file
> #t/htdocs/filter/subrequest.txt
> core subrequest
yes, sorry.
> or even better:
>
> out_str_subreq_default
> out_str_subreq_modperl
>
> since these correspond to the SetHandler settings.
will do.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: SubRequest in Filter MP2 [QUESTION]
Posted by Stas Bekman <st...@stason.org>.
> Geoffrey Young wrote:
>> the problem is with the r->main logic in mpxs_ap_run_sub_req.
>>
>> with that logic, what ends up happening is that the data currently
>> being operated on is explicity flushed. this is bad within a
>> (streaming) filter where you are expected to call $f->print yourself,
>> as the data is sent without your permission (you may be operating on
>> it or not want to send it at all). it also seemed to cause infinite
>> loop in my tests because the filter was seeing the same data over and
>> over again.
That's is the problem with streaming filters. Nothing indicates to mod_perl
whether the currently executed filter is a streaming filter or not, in fact I
think you can mix and match both "methods" in the same filter. So $f->print is
not expected, really.
What you are right about is that mpxs_ap_run_sub_req should flush only if run
from the non-filter handler, and do nothing if run from the filter handler.
I have somewhere a prototype for the new API which tells what phase we are in,
but it's possible that there is a more efficient way to tell the difference.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
Posted by Stas Bekman <st...@stason.org>.
> Geoffrey Young wrote:
>> the problem is with the r->main logic in mpxs_ap_run_sub_req.
>>
>> with that logic, what ends up happening is that the data currently
>> being operated on is explicity flushed. this is bad within a
>> (streaming) filter where you are expected to call $f->print yourself,
>> as the data is sent without your permission (you may be operating on
>> it or not want to send it at all). it also seemed to cause infinite
>> loop in my tests because the filter was seeing the same data over and
>> over again.
That's is the problem with streaming filters. Nothing indicates to mod_perl
whether the currently executed filter is a streaming filter or not, in fact I
think you can mix and match both "methods" in the same filter. So $f->print is
not expected, really.
What you are right about is that mpxs_ap_run_sub_req should flush only if run
from the non-filter handler, and do nothing if run from the filter handler.
I have somewhere a prototype for the new API which tells what phase we are in,
but it's possible that there is a more efficient way to tell the difference.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: SubRequest in Filter MP2 [QUESTION]
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>
> Stas Bekman wrote:
>
>> Craig Shelley wrote:
>>
>>>> I'll take a look at it. But you didn't supply a complete bug report
>>>> as explained http://perl.apache.org/bugs/. Please do so.
>
>
> I think I've got this figured out.
>
> the problem is with the r->main logic in mpxs_ap_run_sub_req.
>
> with that logic, what ends up happening is that the data currently being
> operated on is explicity flushed. this is bad within a (streaming)
> filter where you are expected to call $f->print yourself, as the data is
> sent without your permission (you may be operating on it or not want to
> send it at all). it also seemed to cause infinite loop in my tests
> because the filter was seeing the same data over and over again.
>
> I can't really understand the reason behind the code anyway, since I
> can't see anywhere in core where such logic is applied before
> ap_run_sub_request - everyone seems to call without regard to where in
> the data stream they happen to be, so I don't get why mod_perl should be
> any different. indeed commenting it out fixes the problem for me.
> however, removing that logic causes api/lookup_uri2.t to fail, but I
> suspect this is an issue with puts() rather than the subrequest
> mechanism - changing puts() to print() makes everything work just fine.
> does puts() write directly to the wire, bypassing filters?
Sorry, but that's cheating ;)
rputs() never flushes data,
print() flushes if $| == 1;
Please don't remove rputs, it's there for a reason.
If you fix lookup_uri2's handler to be:
sub handler {
my $r = shift;
subrequest($r, 'myplan');
local $| = 0;
$r->print("ok 2\n");
subrequest($r, 'ok3');
Apache::OK;
}
You get:
ok 1
ok 3
ok 2
Confused test output: test 3 answered after test 3
ok
which is wrong.
So there is no problem with the r->main logic in mpxs_ap_run_sub_req, it's
there for exactly this reason.
I wonder why $| is on? must have forgotten to localize $| setting somewhere.
> anyway, attached is a patch against current cvs - fixes and a few
> filtering subrequest tests. note that the patch does not mention the
> removal of xs/Apache/SubRequest/Apache__SubRequest.h, which is no longer
> needed, so I guess you should remove that file by hand before compiling.
>
> craig - note that this patch affects the autogenerated code, so in order
> to get it to work you'll need to apply it, then run make realclean, perl
> Makefile.PL, etc.
and you forgot to add to the patch a new file
#t/htdocs/filter/subrequest.txt
core subrequest
regarding new tests, do you mind calling them:
out_str_subreq_core
out_str_subreq_perl
since 'sub' is too confusing, or even better:
out_str_subreq_default
out_str_subreq_modperl
since these correspond to the SetHandler settings.
Thanks.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: SubRequest in Filter MP2 [QUESTION]
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>
> Stas Bekman wrote:
>
>> Craig Shelley wrote:
>>
>>>> I'll take a look at it. But you didn't supply a complete bug report
>>>> as explained http://perl.apache.org/bugs/. Please do so.
>
>
> I think I've got this figured out.
>
> the problem is with the r->main logic in mpxs_ap_run_sub_req.
>
> with that logic, what ends up happening is that the data currently being
> operated on is explicity flushed. this is bad within a (streaming)
> filter where you are expected to call $f->print yourself, as the data is
> sent without your permission (you may be operating on it or not want to
> send it at all). it also seemed to cause infinite loop in my tests
> because the filter was seeing the same data over and over again.
>
> I can't really understand the reason behind the code anyway, since I
> can't see anywhere in core where such logic is applied before
> ap_run_sub_request - everyone seems to call without regard to where in
> the data stream they happen to be, so I don't get why mod_perl should be
> any different. indeed commenting it out fixes the problem for me.
> however, removing that logic causes api/lookup_uri2.t to fail, but I
> suspect this is an issue with puts() rather than the subrequest
> mechanism - changing puts() to print() makes everything work just fine.
> does puts() write directly to the wire, bypassing filters?
Sorry, but that's cheating ;)
rputs() never flushes data,
print() flushes if $| == 1;
Please don't remove rputs, it's there for a reason.
If you fix lookup_uri2's handler to be:
sub handler {
my $r = shift;
subrequest($r, 'myplan');
local $| = 0;
$r->print("ok 2\n");
subrequest($r, 'ok3');
Apache::OK;
}
You get:
ok 1
ok 3
ok 2
Confused test output: test 3 answered after test 3
ok
which is wrong.
So there is no problem with the r->main logic in mpxs_ap_run_sub_req, it's
there for exactly this reason.
I wonder why $| is on? must have forgotten to localize $| setting somewhere.
> anyway, attached is a patch against current cvs - fixes and a few
> filtering subrequest tests. note that the patch does not mention the
> removal of xs/Apache/SubRequest/Apache__SubRequest.h, which is no longer
> needed, so I guess you should remove that file by hand before compiling.
>
> craig - note that this patch affects the autogenerated code, so in order
> to get it to work you'll need to apply it, then run make realclean, perl
> Makefile.PL, etc.
and you forgot to add to the patch a new file
#t/htdocs/filter/subrequest.txt
core subrequest
regarding new tests, do you mind calling them:
out_str_subreq_core
out_str_subreq_perl
since 'sub' is too confusing, or even better:
out_str_subreq_default
out_str_subreq_modperl
since these correspond to the SetHandler settings.
Thanks.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> Craig Shelley wrote:
>
>>> I'll take a look at it. But you didn't supply a complete bug report
>>> as explained http://perl.apache.org/bugs/. Please do so.
I think I've got this figured out.
the problem is with the r->main logic in mpxs_ap_run_sub_req.
with that logic, what ends up happening is that the data currently being
operated on is explicity flushed. this is bad within a (streaming) filter
where you are expected to call $f->print yourself, as the data is sent
without your permission (you may be operating on it or not want to send it
at all). it also seemed to cause infinite loop in my tests because the
filter was seeing the same data over and over again.
I can't really understand the reason behind the code anyway, since I can't
see anywhere in core where such logic is applied before ap_run_sub_request -
everyone seems to call without regard to where in the data stream they
happen to be, so I don't get why mod_perl should be any different. indeed
commenting it out fixes the problem for me.
however, removing that logic causes api/lookup_uri2.t to fail, but I suspect
this is an issue with puts() rather than the subrequest mechanism - changing
puts() to print() makes everything work just fine. does puts() write
directly to the wire, bypassing filters?
anyway, attached is a patch against current cvs - fixes and a few filtering
subrequest tests. note that the patch does not mention the removal of
xs/Apache/SubRequest/Apache__SubRequest.h, which is no longer needed, so I
guess you should remove that file by hand before compiling.
craig - note that this patch affects the autogenerated code, so in order to
get it to work you'll need to apply it, then run make realclean, perl
Makefile.PL, etc.
--Geoff
Re: SubRequest in Filter MP2 [QUESTION]
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> Craig Shelley wrote:
>
>>> I'll take a look at it. But you didn't supply a complete bug report
>>> as explained http://perl.apache.org/bugs/. Please do so.
I think I've got this figured out.
the problem is with the r->main logic in mpxs_ap_run_sub_req.
with that logic, what ends up happening is that the data currently being
operated on is explicity flushed. this is bad within a (streaming) filter
where you are expected to call $f->print yourself, as the data is sent
without your permission (you may be operating on it or not want to send it
at all). it also seemed to cause infinite loop in my tests because the
filter was seeing the same data over and over again.
I can't really understand the reason behind the code anyway, since I can't
see anywhere in core where such logic is applied before ap_run_sub_request -
everyone seems to call without regard to where in the data stream they
happen to be, so I don't get why mod_perl should be any different. indeed
commenting it out fixes the problem for me.
however, removing that logic causes api/lookup_uri2.t to fail, but I suspect
this is an issue with puts() rather than the subrequest mechanism - changing
puts() to print() makes everything work just fine. does puts() write
directly to the wire, bypassing filters?
anyway, attached is a patch against current cvs - fixes and a few filtering
subrequest tests. note that the patch does not mention the removal of
xs/Apache/SubRequest/Apache__SubRequest.h, which is no longer needed, so I
guess you should remove that file by hand before compiling.
craig - note that this patch affects the autogenerated code, so in order to
get it to work you'll need to apply it, then run make realclean, perl
Makefile.PL, etc.
--Geoff
Re: SubRequest in Filter MP2 [QUESTION]
Posted by Stas Bekman <st...@stason.org>.
Craig Shelley wrote:
> On Tue, 2003-08-26 at 19:03, Stas Bekman wrote:
>
>>Thanks, but you have missed the core dump's backtrace.
>
> I am sorry but I have never used core files before, so forgive me if I
> have done this all wrong.
No worries, this task is not trivial. Your trace is almost perfect. The only
missing things are the arguments to the functions in the trace. In order to
get the arguments you need to rebuild mp with MP_DEBUG=1 as explained here:
http://perl.apache.org/docs/2.0/user/help/help.html#Resolving_Segmentation_Faults
> (gdb) backtrace
> #0 0x4051cf58 in modperl_wbucket_flush () from
> /usr/lib/apache2/modules/mod_perl.so
> #1 0x4066f5de in XS_Apache__SubRequest_run () from
> /usr/local/lib/perl/5.8.0/auto/Apache/SubRequest/SubRequest.so
Normally you should rebuild perl and apache with appropriate options as
explained at the URL above to get the arguments for the perl and apache
functions, but in this case the bug is most likely in mod_perl, so only
rebuilding mod_perl with MP_DEBUG=1, getting a new segfault and a new trace
will do.
> #2 0x405ad7ef in Perl_pp_entersub () from /usr/lib/libperl.so.5.8
> #3 0x405a720a in Perl_runops_standard () from /usr/lib/libperl.so.5.8
> #4 0x4054fa32 in Perl_call_sv () from /usr/lib/libperl.so.5.8
> #5 0x4054f837 in Perl_call_sv () from /usr/lib/libperl.so.5.8
> #6 0x405195da in modperl_callback () from
> /usr/lib/apache2/modules/mod_perl.so
> #7 0x4051c7ae in modperl_run_filter () from
> /usr/lib/apache2/modules/mod_perl.so
> #8 0x4051cba7 in modperl_output_filter_handler () from
> /usr/lib/apache2/modules/mod_perl.so
> #9 0x0807e66b in ap_pass_brigade ()
> #10 0x08084c15 in ap_core_translate ()
> #11 0x08073b0a in ap_run_handler ()
> #12 0x0807401e in ap_invoke_handler ()
> #13 0x0806767f in ap_process_request ()
> #14 0x080638ed in _start ()
> #15 0x0815e3f8 in ?? ()
> #16 0x00000004 in ?? ()
> #17 0x0815e3f8 in ?? ()
>
> I have not included the core file here because it was ~ 3Mb
> If you need it please let me know
That was a wise decision. A core file is not very useful for our purposes if
taken away from the setup it was originated from. Not talking about the fact
that posting large emails is not appreciated. If such a need rises, one needs
to upload the file somewhere on the web and post the URL to that file instead.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
Posted by Craig Shelley <cr...@microtron.org.uk>.
On Tue, 2003-08-26 at 19:03, Stas Bekman wrote:
> Thanks, but you have missed the core dump's backtrace.
I am sorry but I have never used core files before, so forgive me if I
have done this all wrong.
I configured apache to only have one server process.
Then using gdb, I connected to the server process and told it to
continue execution.
I then made a request to the server, causing it to crash.
Heres what I got:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 22572)]
0x4051cf58 in modperl_wbucket_flush () from
/usr/lib/apache2/modules/mod_perl.so
(gdb) backtrace
#0 0x4051cf58 in modperl_wbucket_flush () from
/usr/lib/apache2/modules/mod_perl.so
#1 0x4066f5de in ?? ()
(gdb) generate-core-file
Saved corefile core.22572
(gdb) quit
# gdb /usr/sbin/apache2 core.22572
<Gdb reported various libraries loading here>
#0 0x4051cf58 in modperl_wbucket_flush () from
/usr/lib/apache2/modules/mod_perl.so
(gdb) backtrace
#0 0x4051cf58 in modperl_wbucket_flush () from
/usr/lib/apache2/modules/mod_perl.so
#1 0x4066f5de in XS_Apache__SubRequest_run () from
/usr/local/lib/perl/5.8.0/auto/Apache/SubRequest/SubRequest.so
#2 0x405ad7ef in Perl_pp_entersub () from /usr/lib/libperl.so.5.8
#3 0x405a720a in Perl_runops_standard () from /usr/lib/libperl.so.5.8
#4 0x4054fa32 in Perl_call_sv () from /usr/lib/libperl.so.5.8
#5 0x4054f837 in Perl_call_sv () from /usr/lib/libperl.so.5.8
#6 0x405195da in modperl_callback () from
/usr/lib/apache2/modules/mod_perl.so
#7 0x4051c7ae in modperl_run_filter () from
/usr/lib/apache2/modules/mod_perl.so
#8 0x4051cba7 in modperl_output_filter_handler () from
/usr/lib/apache2/modules/mod_perl.so
#9 0x0807e66b in ap_pass_brigade ()
#10 0x08084c15 in ap_core_translate ()
#11 0x08073b0a in ap_run_handler ()
#12 0x0807401e in ap_invoke_handler ()
#13 0x0806767f in ap_process_request ()
#14 0x080638ed in _start ()
#15 0x0815e3f8 in ?? ()
#16 0x00000004 in ?? ()
#17 0x0815e3f8 in ?? ()
I have not included the core file here because it was ~ 3Mb
If you need it please let me know
--
Craig Shelley <cr...@microtron.org.uk>
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
Posted by Stas Bekman <st...@stason.org>.
Craig Shelley wrote:
>>I'll take a look at it. But you didn't supply a complete bug report as
>>explained http://perl.apache.org/bugs/. Please do so.
> Here is that bug report related to the earlier postings.
> -------------8<---------- Start Bug Report ------------8<----------
> 1. Problem Description:
[...]
> 3. This is the core dump trace: (if you get a core dump):
>
> [CORE TRACE COMES HERE]
Thanks, but you have missed the core dump's backtrace.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Craig Shelley wrote:
> Hello again..
>
>
>>On Thu, 2003-09-04 at 14:21, Geoffrey Young wrote:
>>
>>see Apache::SSI for mp1 - it does exactly what you are trying to do
>
> and
>
>>is
>>subclassable, so you can add your own tags/functionality if you want.
>>
>
> That is exactly what I am already doing.
> When using #exec directive I noticed I could not set the headers
> properly.
typically, a subrequest gets its headers from the current request.
if you want to alter them, use $r->headers_in->set, but this is generally
only used to test what-if scenarios: what if the current request had a
cookie, could it access this document?
anyway, if you need that, then you could probably create your own subclass
and override ssi_exec to simply set the incoming headers and then
SUPER::ssi_exec.
or something like that (off the top of my head, anyway ;)
>
>
>>see recipe 5.7 in the mod_perl developer's cookbook for that, or look
>
> at
>
>>the
>>Apache::SSI source, which does it a different way.
>
>
> That is something i have yet to get my hands on!
the book has a simpler example as well, but you should be able to figure out
the important LWP bits from the online code example
http://www.modperlcookbook.org/code/ch05/Cookbook/SubRequestContent.pm
--Geoff
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
Posted by Craig Shelley <cr...@microtron.org.uk>.
Hello again..
>
> On Thu, 2003-09-04 at 14:21, Geoffrey Young wrote:
>
> see Apache::SSI for mp1 - it does exactly what you are trying to do
and
> is
> subclassable, so you can add your own tags/functionality if you want.
>
That is exactly what I am already doing.
When using #exec directive I noticed I could not set the headers
properly.
> see recipe 5.7 in the mod_perl developer's cookbook for that, or look
at
> the
> Apache::SSI source, which does it a different way.
That is something i have yet to get my hands on!
--
Craig Shelley <cr...@microtron.org.uk>
Homepage: <http://www.microtron.org.uk>
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
Posted by Craig Shelley <cr...@microtron.org.uk>.
Hello..
Just Forwarding this to the list
> Having no idea as to how the internals of modperl and apache actually
> work, this may seem like a bit of a dumb suggestion.
>
> When doing a subrequest from within a filter, the most ideal situation
> would be to have access to the output from within the same filter.
> I don't know how this would be best done, but one example i can think
of
> would be maybe to be given access to file handle which can be read
from.
> The data from the subrequest can then be processed and incorporated as
> required.
>
> The reason I have ended up fiddling around with subrequests in filters
> is because i was originally writing a few extensions for SSI in MP1.
> My original plan was to create a small library of includable objects
> such as hit counters, fortune generators and photo albums etc
> The idea then was that other people with local access to my server can
> create simple html files that contain SSI directives to include the
> various objects.
>
> It was all going extremely well, until I tried to set a cookie from
> within a subrequest.
> After that, i ran into a whole load of trouble trying to capture the
> output from a subrequest, and ended up turning to mp2
>
> I was wondering if there are any other avenues I should explore in
order
> to set up such a system.
>
> Thank you for spending time on this problem I appreciate it greatly
>
---------
On Thu, 2003-09-04 at 14:21, Geoffrey Young wrote:
see Apache::SSI for mp1 - it does exactly what you are trying to do and
is
subclassable, so you can add your own tags/functionality if you want.
>> After that, i ran into a whole load of trouble trying to capture the
>> output from a subrequest
see recipe 5.7 in the mod_perl developer's cookbook for that, or look at
the
Apache::SSI source, which does it a different way.
--
Craig Shelley <cr...@microtron.org.uk>
Homepage: <http://www.microtron.org.uk>
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
Posted by Craig Shelley <cr...@microtron.org.uk>.
Hi All,
On Wed, 2003-08-27 at 02:33, Geoffrey Young wrote:
> hi craig.
>
> before we continue, please try the latest cvs (without the patch I sent)
> and see if your stuff segfaults there. if not, at least we know we've
> isolated the segfault and just have bad logic to fix :)
Well:
It seg faulted again :(
Here is what the log got:
[Fri Aug 29 17:45:00 2003] [notice] child pid 14541 exit signal Segmentation fault (11)
Here is a Backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 14541)]
0x4052295c in modperl_wbucket_flush (wb=0x0, add_flush_bucket=0) at modperl_filter.c:180
180 if (wb->outcnt) {
(gdb) backtrace
#0 0x4052295c in modperl_wbucket_flush (wb=0x0, add_flush_bucket=0) at modperl_filter.c:180
#1 0x406801f2 in ?? ()
When i run gdb on the core file...
#0 0x4052295c in modperl_wbucket_flush (wb=0x0, add_flush_bucket=0) at modperl_filter.c:180
180 if (wb->outcnt) {
(gdb) backtrace
#0 0x4052295c in modperl_wbucket_flush (wb=0x0, add_flush_bucket=0) at modperl_filter.c:180
#1 0x406801f2 in mpxs_ap_run_sub_req (my_perl=0x8148580, r=0x81a9418) at Apache__SubRequest.h:10
#2 0x406808da in XS_Apache__SubRequest_run (my_perl=0x8148580, cv=0x81965fc) at SubRequest.xs:83
#3 0x405bc7ef in Perl_pp_entersub () from /usr/lib/libperl.so.5.8
#4 0x405b620a in Perl_runops_standard () from /usr/lib/libperl.so.5.8
#5 0x4055ea32 in Perl_call_sv () from /usr/lib/libperl.so.5.8
#6 0x4055e837 in Perl_call_sv () from /usr/lib/libperl.so.5.8
#7 0x4051d6d5 in modperl_callback (my_perl=0x8148580, handler=0x80db808, p=0x815c920, r=0x815c958, s=0x80db858, args=0x8145598)
at modperl_callback.c:53
#8 0x405231cd in modperl_run_filter (filter=0x8162938) at modperl_filter.c:400
#9 0x40523f51 in modperl_output_filter_handler (f=0x815e440,
bb=0x815e5a8) at modperl_filter.c:761
#10 0x0807e66b in ap_pass_brigade ()
#11 0x08084c15 in ap_core_translate ()
#12 0x08073b0a in ap_run_handler ()
#13 0x0807401e in ap_invoke_handler ()
#14 0x0806767f in ap_process_request ()
#15 0x080638ed in _start ()
#16 0x0815c958 in ?? ()
#17 0x00000004 in ?? ()
#18 0x0815c958 in ?? ()
If you would like some more info please let me know, because I am eager
to help solve this problem.
PS -- I am running the same test scripts as I mentioned in previous
posts.
--
Craig Shelley <cr...@microtron.org.uk>
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Craig Shelley wrote:
> MP_AP_PREFIX => /home/craig/temp/mod_perl-1.99_09/
hi craig.
before we continue, please try the latest cvs (without the patch I sent)
and see if your stuff segfaults there. if not, at least we know we've
isolated the segfault and just have bad logic to fix :)
if you need help with cvs, see
http://perl.apache.org/docs/2.0/user/install/install.html#Downloading_the_mod_perl_Source
--Geoff
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
Posted by Craig Shelley <cr...@microtron.org.uk>.
> I'll take a look at it. But you didn't supply a complete bug report as
> explained http://perl.apache.org/bugs/. Please do so.
Hi,
Here is that bug report related to the earlier postings.
-------------8<---------- Start Bug Report ------------8<----------
1. Problem Description:
[DESCRIBE THE PROBLEM HERE]
2. Used Components and their Configuration:
*** using lib/Apache/BuildConfig.pm
*** Makefile.PL options:
MP_AP_PREFIX => /home/craig/temp/mod_perl-1.99_09/
MP_COMPAT_1X => 1
MP_GENERATE_XS => 1
MP_LIBNAME => mod_perl
MP_USE_DSO => 1
MP_USE_STATIC => 1
*** /usr/local/bin/httpd -V
Server version: Apache/2.0.47
Server built: Jul 15 2003 14:07:14
Server's Module Magic Number: 20020903:4
Architecture: 32-bit
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT=""
-D SUEXEC_BIN="/usr/lib/apache2/suexec2"
-D DEFAULT_PIDLOG="/var/run/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="/var/run/accept.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="/etc/apache2/mime.types"
-D SERVER_CONFIG_FILE="/etc/apache2/apache2.conf"
*** /usr/bin/perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Platform:
osname=linux, osvers=2.4.21-xfs+ti1211,
archname=i386-linux-thread-multi
uname='linux kosh 2.4.21-xfs+ti1211 #1 sat jul 12 10:35:04 est 2003
i686 gnulinux '
config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN
-Dcccdlflags=-fPIC -Darchname=i386-linux -Dprefix=/usr
-Dprivlib=/usr/share/perl/5.8.0 -Darchlib=/usr/lib/perl/5.8.0
-Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5
-Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local
-Dsitelib=/usr/local/share/perl/5.8.0
-Dsitearch=/usr/local/lib/perl/5.8.0 -Dman1dir=/usr/share/man/man1
-Dman3dir=/usr/share/man/man3 -Dman1ext=1 -Dman3ext=3perl
-Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -Uusenm
-Duseshrplib -Dlibperl=libperl.so.5.8.0 -Dd_dosuid -des'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN
-fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O3',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing'
ccversion='', gccversion='3.3.1 20030722 (Debian prerelease)',
gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt
perllibs=-ldl -lm -lpthread -lc -lcrypt
libc=/lib/libc-2.3.1.so, so=so, useshrplib=true,
libperl=libperl.so.5.8.0
gnulibc_version='2.3.1'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES
PERL_IMPLICIT_CONTEXT
Built under linux
Compiled at Jul 30 2003 10:52:58
%ENV:
PERL_LWP_USE_HTTP_10="1"
@INC:
/etc/perl
/usr/local/lib/perl/5.8.0
/usr/local/share/perl/5.8.0
/usr/lib/perl5
/usr/share/perl5
/usr/lib/perl/5.8.0
/usr/share/perl/5.8.0
/usr/local/lib/site_perl
.
3. This is the core dump trace: (if you get a core dump):
[CORE TRACE COMES HERE]
This report was generated by t/REPORT on Tue Aug 26 17:17:34 2003 GMT.
-------------8<---------- End Bug Report --------------8<----------
__________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
--
Craig Shelley <cr...@microtron.org.uk>
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
Posted by Stas Bekman <st...@stason.org>.
Craig Shelley wrote:
>>does anything change if you use
>>
>> $rr = $f->$r->lookup_uri("subrequest.txt", $f->next);
>
>
> No it doesn't seem any different, the server still seg faults.
> When it does this, it produces no output at all.
>
> telnet 127.0.0.1 80
> Trying 127.0.0.1...
> Connected to 127.0.0.1.
> Escape character is '^]'.
> GET / HTTP/1.0
>
> Connection closed by foreign host.
I'll take a look at it. But you didn't supply a complete bug report as
explained http://perl.apache.org/bugs/. Please do so.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
Posted by Craig Shelley <cr...@microtron.org.uk>.
> does anything change if you use
>
> $rr = $f->$r->lookup_uri("subrequest.txt", $f->next);
No it doesn't seem any different, the server still seg faults.
When it does this, it produces no output at all.
telnet 127.0.0.1 80
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
GET / HTTP/1.0
Connection closed by foreign host.
Thank you for looking into this.
--
Craig Shelley <cr...@microtron.org.uk>
Just don't create a file called -rf. :-)
-- Larry Wall in <11...@jpl-devvax.JPL.NASA.GOV>
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html