Hey list,
To be able to pass some notes across php subrequest calls which in turn
call a mod_perl handlers we've overriden Apache::SubRequest::run() in
startup.pl like so:
### save the original method
*NFN::run_save = \&Apache::SubRequest::run;
## build our custom version
sub NFN::run_custom {
my $subr = shift(@_);
## copy our notes into the subrequest
my $parent_notes = $subr->main->notes();
for my $key (keys(%$parent_notes)) {
if ($key =~ /^NFN_/) {
$subr->notes($key, $parent_notes->{$key});
}
}
my @retval = ();
## i don't know if run() returns differently in
## scalar vs. array context, so i've split up the
## call here. (normally, i would just say
## return NFN::run_save() but i can't return until later
if(wantarray) {
## call the original method
@retval = NFN::run_save($subr, @_);
}
else {
## call the original method
my $retval = NFN::run_save($subr, @_);
@retval = ($retval);
}
## copy our notes back into the parent
my $child_notes = $subr->notes();
for my $key (keys(%$child_notes)) {
if ($key =~ /^NFN_/) {
$subr->main->notes($key, $child_notes->{$key});
}
}
return wantarray ? @retval : $retval[0];
}
### make calls to Apache::Subrequest::run get handled by
### our custom method.
*Apache::SubRequest::run = \&NFN::run_custom;
This works as intended but has a peculiar side effect. My development
machine's browser, mozilla 1.0 rc3, segfaults the apache process when
serving a particular page on our sites. My laptop has the same exact
build and does not do this at all. I've seen 1 machine in our office do
this on IE 6.0 , but only on a different page. In all cases when apache
segfaults, about 1/4 of the html for the page comes out. This 1/4 is
served by a php page which is called via $subr->run() from a registry
script. The php subrequest finishes normally, but the registry script
causes the segfault at the next print command after the $subr->run() call.
Watching my log files I can see that other machines are also segfaulting
apache processes. This behavior stops when I remove our modification to
the run method. The absolute bizarre thing is that almost all pages on
our site work exactly the same way, call the same php files, but only
one segfaults apache from my browser, but on the IE machine, it's a
different page that segfaults.
Anyhow, I've managed to grab a backtrace from when my browser hits the
server:
Program received signal SIGSEGV, Segmentation fault.
0x08138498 in ap_bwrite ()
(gdb) bt
#0 0x08138498 in ap_bwrite ()
#1 0x08147572 in ap_rwrite ()
#2 0x08127e31 in XS_Apache_write_client ()
#3 0x08127c52 in XS_Apache_print ()
#4 0x0819c12c in Perl_pp_entersub ()
#5 0x08157645 in S_call_body ()
#6 0x0815721b in perl_call_sv ()
#7 0x081570a1 in perl_call_method ()
#8 0x08197a16 in Perl_pp_print ()
#9 0x08196a58 in Perl_runops_standard ()
#10 0x08157654 in S_call_body ()
#11 0x08157431 in perl_call_sv ()
#12 0x081570a1 in perl_call_method ()
#13 0x0811d8e2 in perl_call_handler ()
#14 0x0811d1f9 in perl_run_stacked_handlers ()
#15 0x0811bca9 in perl_handler ()
#16 0x08139191 in ap_invoke_handler ()
#17 0x08149a6c in process_request_internal ()
#18 0x08149aee in ap_process_request ()
#19 0x08142984 in child_main ()
#20 0x08142b00 in make_child ()
#21 0x08142c36 in startup_children ()
#22 0x081431fb in standalone_main ()
#23 0x081439e8 in main ()
#24 0x400ef507 in __libc_start_main (main=0x8143680 <main>, argc=2,
ubp_av=0xbffffad4,
init=0x8073d5c <_init>, fini=0x81da5f0 <_fini>,
rtld_fini=0x4000dc14 <_dl_fini>,
stack_end=0xbffffacc) at ../sysdeps/generic/libc-start.c:129
--
--
Daniel Bohling
NewsFactor Network
