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
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 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
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
[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: VirtualHost * DocumentRoot
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
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
