Re: SubRequest in Filter MP2 [QUESTION]

2003-09-05 Thread Craig Shelley 
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 [EMAIL PROTECTED]

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]

2003-09-05 Thread Geoffrey Young 


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]

2003-09-04 Thread Craig Shelley 
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 [EMAIL PROTECTED]

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]

2003-08-29 Thread Craig Shelley 
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 0x0004 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 [EMAIL PROTECTED]



-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: SubRequest in Filter MP2 [QUESTION]

2003-08-27 Thread Geoffrey Young 


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]

2003-08-27 Thread Stas Bekman 
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 BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] 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]

2003-08-27 Thread Geoffrey Young 

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

  datatagdata

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]

2003-08-27 Thread Stas Bekman 

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 BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] 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]

2003-08-27 Thread Stas Bekman 
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 BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] 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]

2003-08-26 Thread Craig Shelley 

 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 BekmanJAm_pH -- Just Another mod_perl Hacker
 http://stason.org/ mod_perl Guide --- http://perl.apache.org
 mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
 http://modperlbook.org http://apache.org   http://ticketmaster.com
-- 
Craig Shelley [EMAIL PROTECTED]



-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: SubRequest in Filter MP2 [QUESTION]

2003-08-26 Thread Stas Bekman 
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 BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] 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]

2003-08-26 Thread Craig Shelley 
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 0x0004 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 [EMAIL PROTECTED]



-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: SubRequest in Filter MP2 [QUESTION]

2003-08-26 Thread Stas Bekman 
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 0x0004 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 BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] 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]

2003-08-26 Thread Geoffrey Young 


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
Index: t/response/TestAPI/lookup_uri2.pm
===
RCS file: /home/cvspublic/modperl-2.0/t/response/TestAPI/lookup_uri2.pm,v
retrieving revision 1.3
diff -u -r1.3 lookup_uri2.pm
--- t/response/TestAPI/lookup_uri2.pm   27 Apr 2003 04:19:18 -  1.3
+++ t/response/TestAPI/lookup_uri2.pm   26 Aug 2003 19:55:50 -
@@ -11,7 +11,7 @@
 sub myplan {
 my $r = shift;
 
-$r-puts(1..3\nok 1\n);
+$r-print(1..3\nok 1\n);
 
 Apache::OK;
 }
@@ -19,7 +19,7 @@
 sub ok3 {
 my $r = shift;
 
-$r-puts(ok 3\n);
+$r-print(ok 3\n);
 
 Apache::OK;
 }
@@ -35,7 +35,7 @@
 
 subrequest($r, 'myplan');
 
-$r-puts(ok 2\n);
+$r-print(ok 2\n);
 
 subrequest($r, 'ok3');
 
Index: xs/maps/apache_functions.map
===
RCS file: /home/cvspublic/modperl-2.0/xs/maps/apache_functions.map,v
retrieving revision 1.64
diff -u -r1.64 apache_functions.map
--- xs/maps/apache_functions.map12 Jun 2003 23:27:03 -  1.64
+++ xs/maps/apache_functions.map26 Aug 2003 19:55:51 -
@@ -95,7 +95,7 @@
 
 PACKAGE=Apache::SubRequest   ISA=Apache::RequestRec
  ap_destroy_sub_req  | | r | DESTROY
- ap_run_sub_req  | mpxs_ | | run
+ ap_run_sub_req  | | r | run
 
 MODULE=Apache::RequestIO   PACKAGE=Apache::RequestRec
  ap_discard_request_body
Index: xs/tables/current/ModPerl/FunctionTable.pm
===
RCS file: /home/cvspublic/modperl-2.0/xs/tables/current/ModPerl/FunctionTable.pm,v
retrieving revision 1.119
diff -u -r1.119 FunctionTable.pm
--- xs/tables/current/ModPerl/FunctionTable.pm  20 Aug 2003 23:20:14 -  1.119
+++ xs/tables/current/ModPerl/FunctionTable.pm  26 Aug 2003 19:55:56 -
@@ -6170,24 +6170,6 @@
 ]
   },
   {
-'return_type' = 'int',
-'name' = 'mpxs_ap_run_sub_req',
-'attr' = [
-  'static',
-  '__inline__'
-],
-'args' = [
-  {
-'type' = 'PerlInterpreter *',
-'name' = 'my_perl'
-  },
-  {
-'type' = 'request_rec *',
-'name' = 'r'
-  }
-]
-  },
-  {
 'return_type' = 'apr_size_t',
 'name' = 'mpxs_ap_rvputs',
 'attr' = [

--- /dev/null   2003-01-30 05:24:37.0 -0500
+++ t/filter/TestFilter/out_str_sub_core.pm 2003-08-26 15:51:40.0 -0400
@@ -0,0 +1,78 @@
+package TestFilter::out_str_sub_core;
+
+use strict;
+use warnings FATAL = 'all';
+
+use Apache::Test;
+use Apache::TestUtil;
+
+use Apache::RequestRec ();
+use Apache::RequestIO ();
+use Apache::SubRequest ();
+
+use Apache::Filter ();
+
+use Apache::Const -compile = qw(OK);
+
+# include the contents of a subrequest
+# in the filter, a la mod_include's 
+# !--#include virtual=/subrequest --
+
+sub include {
+
+my $filter = shift;
+
+unless ($filter-ctx) {
+# don't forget to remove the C-L header
+$filter-r-headers_out-unset('Content-Length');
+
+$filter-ctx(1);
+}
+
+while ($filter-read(my $buffer, 1024)){
+
+if ($buffer eq tag\n) {
+my $sub = $filter-r-lookup_uri('/core_subrequest/subrequest.txt');
+my $rc = $sub-run;
+

Re: SubRequest in Filter MP2 [QUESTION]

2003-08-25 Thread Geoffrey Young 


 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]

2003-08-25 Thread Craig Shelley 

 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 [EMAIL PROTECTED]



Just don't create a file called -rf.  :-)
 -- Larry Wall in [EMAIL PROTECTED]



-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: SubRequest in Filter MP2 [QUESTION]

2003-08-25 Thread Stas Bekman 
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 BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] 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