Re: [mp1] consistent segfaults with HTML::Mason
"Geoffrey Young" wrote: > mp1 supports both $$ and :method, so no need to do something special to make > it work for both mp1 and mp2. Aah, I'll pass that onto the Mason folks. Ta. > > Preloading the module and using the explicit Module->handler method syntax > > in httpd.conf seems to have fixed it. > > preloading is required in mp1. the -> syntax is not. Ah, looks like that was it, in that case. Stephen Veiss -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp1] consistent segfaults with HTML::Mason
Stephen wrote: "Stephen" <[EMAIL PROTECTED]> wrote: I'm no expert at debugging C, but I dont think that the above looks too healthy Well, I think I have it figured out, more or less. The root cause of it seemed to be a rather, um, interesting bit of code in HTML::Mason::ApacheHandler which makes use of string eval and sprintf to define the handler() subroutine. The intent was to create a handler() routine suitable for both mod_perl 1 and 2 (prototype of ($$) vs attribute of : method). However, for some reason or another, handler() was being called as a regular sub, with one parameter. mp1 supports both $$ and :method, so no need to do something special to make it work for both mp1 and mp2. Preloading the module and using the explicit Module->handler method syntax in httpd.conf seems to have fixed it. preloading is required in mp1. the -> syntax is not. HTH --Geoff -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp1] consistent segfaults with HTML::Mason
Stephen wrote:
[...]
The intent was to create a handler()
routine suitable for both mod_perl 1 and 2 (prototype of ($$) vs attribute
of : method). However, for some reason or another, handler() was being
called as a regular sub, with one parameter.
I have used the technique documented here:
http://perl.apache.org/docs/2.0/user/porting/porting.html#Method_Handlers
which in short words comes to:
sub handler_mp1 ($$) { &mp1 }
sub handler_mp2 : method { &mp2 }
*handler = MP2 ? \&handler_mp2 : \&handler_mp1;
One thing I forgot to mention, is that : method won't work with perl < 5.6.
So if you can share your solution, I'd it to that section.
__
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: [mp1] consistent segfaults with HTML::Mason
"Stephen" <[EMAIL PROTECTED]> wrote:
> I'm no expert at debugging C, but I dont think that the above looks too
> healthy
Well, I think I have it figured out, more or less. The root cause of it
seemed to be a rather, um, interesting bit of code in
HTML::Mason::ApacheHandler which makes use of string eval and sprintf to
define the handler() subroutine. The intent was to create a handler()
routine suitable for both mod_perl 1 and 2 (prototype of ($$) vs attribute
of : method). However, for some reason or another, handler() was being
called as a regular sub, with one parameter.
Preloading the module and using the explicit Module->handler method syntax
in httpd.conf seems to have fixed it. (Having said that, it seems to be
working without the additional "->handler" now ... *sighs*. Either I failed
to add method handlers to the config before, or I'm collecting on a karmic
debt. Or both).
As for the segfaults, I patched my mod_perl source to return undef in that
situation as opposed to segfault, which seems slightly more reasonable
behaviour. Patch below:
--- src/modules/perl/Apache.xs-origFri Jun 6 12:31:10 2003
+++ src/modules/perl/Apache.xs Thu Aug 28 12:10:53 2003
@@ -2075,7 +2075,10 @@
SvREFCNT_dec(RETVAL); /* in case above did newSV(0) */
cs = (perl_server_config *)get_module_config(s->module_config,
&perl_module);
- TABLE_GET_SET(cs->vars, FALSE);
+if(cs) {
+ TABLE_GET_SET(cs->vars, FALSE);
+}
+else XSRETURN_UNDEF;
}
else XSRETURN_UNDEF;
}
This has taught me more about XS and the um, interesting capabilities of
string eval than I ever wanted to know, I think. Please excuse me whilst I
take a cold shower or three...
Stephen Veiss
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp1] consistent segfaults with HTML::Mason
"Stas Bekman" <[EMAIL PROTECTED]> wrote:
> Wearing my bug-tender cap, but not taking the ownership of this bug, I
should
> say that your backtrace could be much more useful if you have had rebuilt
> apache/perl/mod_perl with debugging symbols enabled. When you do that the
> trace will show the arguments to the functions.
http://perl.apache.org/bugs/
> provides the details on how to do that.
Hrm. I thought I had. Let me try it again.
Aha. It would seem that make install strips symbols or something...
Program received signal SIGSEGV, Segmentation fault.
0x808ed0d in XS_Apache_dir_config (cv=0x81ce8cc) at Apache.c:3114
3114TABLE_GET_SET(cs->vars, FALSE);
(gdb) bt
#0 0x808ed0d in XS_Apache_dir_config (cv=0x81ce8cc) at Apache.c:3114
#1 0x810c3b3 in Perl_pp_entersub ()
#2 0x81066e0 in Perl_runops_standard ()
#3 0x80c55ba in S_call_body ()
#4 0x80c56fe in Perl_eval_sv ()
#5 0x80860ea in perl_require_module (name=0x8324f7c
"HTML::Mason::ApacheHandler", s=0x827019c) at perl_util.c:550
#6 0x807ffdc in perl_call_handler (sv=0x81ce9ec, r=0x8323d34, args=0x0) at
mod_perl.c:1590
#7 0x807f9d1 in perl_run_stacked_handlers (hook=0x815f619 "PerlHandler",
r=0x8323d34, handlers=0x81cea4c) at mod_perl.c:1374
#8 0x807dd37 in perl_handler (r=0x8323d34) at mod_perl.c:897
#9 0x809d811 in ap_invoke_handler (r=0x8323d34) at http_config.c:518
#10 0x80b3470 in process_request_internal (r=0x8323d34) at
http_request.c:1324
#11 0x80b3900 in ap_internal_redirect (new_uri=0x8323d0c "/index.mhtml",
r=0x8323034) at http_request.c:1461
#12 0x8076042 in handle_dir (r=0x8323034) at mod_dir.c:174
#13 0x809d811 in ap_invoke_handler (r=0x8323034) at http_config.c:518
#14 0x80b3470 in process_request_internal (r=0x8323034) at
http_request.c:1324
#15 0x80b34da in ap_process_request (r=0x8323034) at http_request.c:1340
#16 0x80a9dcb in child_main (child_num_arg=0) at http_main.c:4653
#17 0x80a9f8d in make_child (s=0x819c034, slot=0, now=1062020715) at
http_main.c:4768
#18 0x80aa106 in startup_children (number_to_start=2) at http_main.c:4850
#19 0x80aa7a4 in standalone_main (argc=4, argv=0xbfbffa78) at
http_main.c:5169
#20 0x80ab004 in main (argc=4, argv=0xbfbffa78) at http_main.c:5511
#21 0x8064a6a in _start ()
(gdb) list
3109s = r && r->server ? r->server : perl_get_startup_server();
3110if (s && s->module_config) {
3111SvREFCNT_dec(RETVAL); /* in case above did newSV(0) */
3112cs = (perl_server_config
*)get_module_config(s->module_config,
3113
&perl_module);
3114TABLE_GET_SET(cs->vars, FALSE);
3115}
3116else XSRETURN_UNDEF;
3117}
3118
(gdb) print cs
$4 = (perl_server_config *) 0x0
(gdb) print s
$6 = (server_rec *) 0x0
I'm no expert at debugging C, but I dont think that the above looks too
healthy
Stephen Veiss
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp1] consistent segfaults with HTML::Mason
Stephen wrote: [...] The GDB backtrace output (from debugging httpd -X) is as follows: (gdb) bt #0 0x808d079 in XS_Apache_dir_config () #1 0x810a7f7 in Perl_pp_entersub () #2 0x8104b24 in Perl_runops_standard () #3 0x80c39fe in Perl_call_sv () #4 0x80c3b42 in Perl_eval_sv () #5 0x80846ce in perl_require_module () #6 0x807f1ac in perl_call_handler () #7 0x807ecb4 in perl_run_stacked_handlers () #8 0x807d7a3 in perl_handler () #9 0x809bb8d in ap_invoke_handler () #10 0x80b185c in ap_some_auth_required () #11 0x80b1cec in ap_internal_redirect () #12 0x8076052 in ap_get_server_built () #13 0x809bb8d in ap_invoke_handler () #14 0x80b185c in ap_some_auth_required () #15 0x80b18c6 in ap_process_request () #16 0x80a817f in ap_child_terminate () #17 0x80a8341 in ap_child_terminate () #18 0x80a84ba in ap_child_terminate () #19 0x80a8b5c in ap_child_terminate () #20 0x80a93bc in main () #21 0x8064a22 in _start () Wearing my bug-tender cap, but not taking the ownership of this bug, I should say that your backtrace could be much more useful if you have had rebuilt apache/perl/mod_perl with debugging symbols enabled. When you do that the trace will show the arguments to the functions. http://perl.apache.org/bugs/ provides the details on how to do that. __ 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
[mp1] consistent segfaults with HTML::Mason
Greetings, I'm not sure if this should be sent here, or to the HTML::Mason list, but as its a segfault, I've sent it here first. I've just upgraded my apache/mod_perl installation, and have run into a few problems. Firstly, all of mod_perl's tests pass (although a few are skipped), and mod_perl itself seems to work (Apache::MP3 was the module I used for testing, which seems to work). However, any attempt to use HTML::Mason::ApacheHandler causes a segmentation fault. I've looked though the various mod_perl and Mason FAQs/documentation, and couldn't find anything regarding this. I'd be most appreciative if anyone could point me in the right direction. My system details are as below - I've included everything that seems to be relevant from the list on http://perl.apache.org/bugs/. I'm running FreeBSD 4.8-RELEASE, Perl 5.8.0, Apache 1.3.28 and mod_perl 1.28. mod_perl was compiled as a static module, using the following command line in the mod_perl source directory: perl Makefile.PL APACHE_SRC=../apache_1.3.28/src APACHE_PREFIX=/usr/local/apache13 DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 The following mod_perl tests were skipped (the rest all completed sucessfully): modules/cookieskipped all skipped: no reason given modules/moduleskipped all skipped: no reason given modules/request...skipped all skipped: no reason given modules/stage.skipped all skipped: no reason given My perl details are as follows: Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=freebsd, osvers=4.8-release, archname=i386-freebsd uname='freebsd holly.mutatorr.net 4.8-release freebsd 4.8-release #0: sat may 17 18:53:46 bst 2003 [EMAIL PROTECTED]:usrsrcsyscompileholly i386 ' config_args='-sde -Dprefix=/usr/local -Darchlib=/usr/local/lib/perl5/5.8.0/m ach -Dprivlib=/usr/local/lib/perl5/5.8.0 -Dman3dir=/usr/local/lib/perl5/5.8. 0/man/man3 -Dsitearch=/usr/local/lib/perl5/site_perl/5.8.0/mach -Dsitelib=/u sr/local/lib/perl5/site_perl/5.8.0 -Dscriptdir=/usr/local/bin -Ui_malloc -Ui _iconv -Uinstallusrbinperl -Dcc=cc -Dccflags=-DAPPLLIB_EXP="/usr/local/lib/p erl5/5.8.0/BSDPAN" -Ui_gdbm -Dusemymalloc=n -Dusethreads=n' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-DAPPLLIB_EXP="/usr/local/lib/perl5/5.8.0/BSDPAN" -DHAS_FPSETMASK -DHAS_FL OATINGPOINT_H -fno-strict-aliasing -I/usr/local/include', optimize='-O -pipe ', cppflags='-DAPPLLIB_EXP="/usr/local/lib/perl5/5.8.0/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='2.95.4 20020320 [FreeBSD]', 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 ='-Wl,-E -L/usr/local/lib' libpth=/usr/lib /usr/local/lib libs=-lm -lc -lcrypt -lutil perllibs=-lm -lc -lcrypt -lutil libc=, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-DPIC -fPIC', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under freebsd Compiled at May 26 2003 00:36:13 @INC: /usr/local/lib/perl5/site_perl/5.8.0/mach /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl /usr/local/lib/perl5/5.8.0/BSDPAN /usr/local/lib/perl5/5.8.0/mach /usr/local/lib/perl5/5.8.0 The GDB backtrace output (from debugging httpd -X) is as follows: (gdb) bt #0 0x808d079 in XS_Apache_dir_config () #1 0x810a7f7 in Perl_pp_entersub () #2 0x8104b24 in Perl_runops_standard () #3 0x80c39fe in Perl_call_sv () #4 0x80c3b42 in Perl_eval_sv () #5 0x80846ce in perl_require_module () #6 0x807f1ac in perl_call_handler () #7 0x807ecb4 in perl_run_stacked_handlers () #8 0x807d7a3 in perl_handler () #9 0x809bb8d in ap_invoke_handler () #10 0x80b185c in ap_some_auth_required () #11 0x80b1cec in ap_internal_redirect () #12 0x8076052 in ap_get_server_built () #13 0x809bb8d in ap_invoke_handler () #14 0x80b185c in ap_some_auth_required () #15 0x80b18c6 in ap_process_request () #16 0x80a817f in ap_child_terminate () #17 0x80a8341 in ap_child_terminate () #18 0x80a84ba in ap_child_terminate () #19 0x80a8b5c in ap_child_terminate () #20 0x80a93bc in main () #21 0x8064a22 in _start () The relavent sections of my httpd.conf are as follows: DocumentRoot /home/stephen/im/p
