This particular problem of not having Apache->request available, even though you run under 'SetHandler perl-script' seems to be due to the use of static variables.
src/modules/perl/modperl_global.c creates a static variable for $r.
static modperl_global_t MP_tls_##gname;
which after expanding macros translates to:
static modperl_global_t *MP_tls_request_rec
Now observe:
Breakpoint 7, modperl_global_request_set (r=0x20e3d738) at modperl_global.c:31
31 MP_dRCFG;
(gdb) n
...
(gdb) n
38 modperl_tls_set_request_rec(r);
(gdb) p *MP_tls_request_rec
$28 = {flags = 0, data = 0x0, name = 0x0}
That's the value of MP_tls_request_rec before setting it to $r
(gdb) n
41 MpReqSET_GLOBAL_REQUEST_On(rcfg);
(gdb) p *MP_tls_request_rec
$29 = {flags = 0, data = 0x0, name = 0x0}As you can see it ain't working. So obviously when later on it tries to get that data out and use it, it fails and hence you get this kind of errors:
Global $r object is not available. Set:\n\tPerlOptions +GlobalRequest\nin httpd.conf at ...
So, are you aware with problems of using static variables on your platform? Is it compiler specific? Does it get them optimized away or something?
If you rebuild your perl with ithreads and APR has ithreads too, which seems to be the case, since it links pthread
*** (apr|apu)-config linking info
-L/usr/local/apache2/lib -lapr-0 -lm -lnsl -lpthread -L/usr/local/apache2/lib -laprutil-0 -ldb-4.2 -lexpat -liconv
and then rebuild mod_perl, it may fare better, as it'll use TLS instead of the static for this particular thing. If your threads implementation is good it should work well.
Another possibility to try is to compile mod_perl statically, but I'm not sure if it's going to make any difference. I'd try a threaded perl first.
BTW, should you explore it on your own (and may be faster machine :) I've attached the gdb debug script I have used. You use it as follows:
console one: gdb --command=debug wait a bit now: console two: t/TEST -v -run t/cgi.t
For more information see: http://perl.apache.org/docs/2.0/devel/debug/c.html#Precooked_gdb_Startup_Scripts
-- __________________________________________________________________ Stas Bekman JAm_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
# This gdb startup script breaks at the mpxs_Apache__Filter_print() # function from the XS code, as an example how you can debug the code # in XS extensions. # # Invoke as: # gdb -command=.debug-modperl-xs # and then run: # t/TEST -v -run -ping=block filter/api # # see ADJUST notes for things that may need to be adjusted
# ADJUST: the path to the httpd executable if needed
file /usr/local/apache2/bin/httpd
handle SIGPIPE nostop
handle SIGPIPE pass
set auto-solib-add 0
define myrun
tbreak main
break ap_run_pre_config
dir /u0/stas/modperl-2.0/src/modules/perl
# ADJUST: the httpd.conf file's path if needed
# ADJUST: add -DPERL_USEITHREADS to debug threaded mpms
run -d `pwd`/t -f `pwd`/t/conf/httpd.conf \
-DONE_PROCESS -DNO_DETATCH -DAPACHE2
continue
end
define sharedap
sharedlibrary apr
sharedlibrary aprutil
#sharedlibrary mod_ssl.so
continue
end
define sharedperl
sharedlibrary libperl
end
define gopoll
b apr_poll
continue
# continue
end
define mybp
sharedlibrary mod_perl.so
#sharedlibrary Apache/RequestIO
sharedlibrary RequestUtil.so
b modperl_response_handler_cgi
b modperl_global_request_set
b modperl_global_request
b modperl_tls_create
# no longer needed and they just make debugging harder under threads
disable 2
disable 3
continue
end
myrun
gopoll
# ADJUST: uncomment if you need to step through the code in apr libs
sharedap
# ADJUST: uncomment if you need to step through the code in perlib
sharedperl
mybp
-- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
