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