more_mason

This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.



Subject: ANNOUCE: HTML::Mason 0.89
From: Jonathan Swartz <swartz@pobox.com>
Date: Fri, 15 Sep 2000 08:03:21 -0700

The URL

    http://masonhq.com/download/HTML-Mason-0.89.tar.gz

has entered CPAN as

  file: $CPAN/authors/id/J/JS/JSWARTZ/HTML-Mason-0.89.tar.gz
  size: 258824 bytes
   md5: d03e77cd42b6995eefeeccb3a0d0b541

This fixes a fatal argument processing bug and system logging bug in 0.88.
We believe this version to be stable again; please send bug reports to the
Mason user's list.

===

Subject: [Fwd: Re: [Mason]Intermittent Segfaults]
From: Mark Hughes <mark@ismltd.com>
Date: Fri, 15 Sep 2000 16:08:15 +0100

Harry Danilevsky wrote:

> Mark Hughes [mailto:mark@ismltd.com] wrote:
>
> > Our sites experience intermittent segfaults
> > (Segmentation Fault (11)) when serving mason generated
> > pages, these seem to be completely random in frequency
> > and called component (though components do share common
> > module code), and occur infrequently, every few thousand
> > requests or so.
> >
> > The servers are very busy, though load and memory usage are light.
> >
> > Setup Details:
> >
> > Mason 0.87 (Just tried 0.88, same intermittent problem)
> > Perl 5.005_03
> > mod_perl 1.24
> > Apache 1.3.12
> > Linux 2.2.16
> >
> > I've tried mason using Apache::Request and CGI.pm to handle
> > %ARGS - same
> > problem.
> >
> > Backtrace, obtained according to mod_perl SUPPORT file
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x80ed2b2 in Perl_pp_entersub ()
> >
> > #0  0x80ed2b2 in Perl_pp_entersub ()
> > #1  0x80bf38c in perl_call_sv ()
> > #2  0x80e13cc in Perl_croak ()
> > #3  0x80ee02a in Perl_sv_upgrade ()
> > #4  0x80c1d82 in Perl_gv_init ()
> > #5  0x80c2e19 in Perl_gv_fetchpv ()
> > #6  0x8087f1e in XS_Apache_finfo ()
> > #7  0x80ecfb6 in Perl_pp_entersub ()
> > #8  0x8116f5d in Perl_runops_standard ()
> > #9  0x80bf3a1 in perl_call_sv ()
> > #10 0x807c1cb in perl_call_handler ()
> > #11 0x807b9db in perl_run_stacked_handlers ()
> > #12 0x8079f5d in perl_handler ()
> > #13 0x80950e3 in ap_invoke_handler ()
> > #14 0x80a85b9 in ap_some_auth_required ()
> > #15 0x80a861c in ap_process_request ()
> > #16 0x809ff0e in ap_child_terminate ()
> > #17 0x80a009c in ap_child_terminate ()
> > #18 0x80a01f9 in ap_child_terminate ()
> > #19 0x80a0826 in ap_child_terminate ()
> > #20 0x80a0fb3 in main ()
> > #21 0x400941eb in __libc_start_main (main=0x80a0c6c <main>, argc=6,
> >     argv=0xbffffc94, init=0x8060090 <_init>, fini=0x811703c <_fini>,
> >     rtld_fini=0x4000a610 <_dl_fini>, stack_end=0xbffffc8c)
> >     at ../sysdeps/generic/libc-start.c:90
> >
> >
> >
> > Any clues on how I can further debug this problem to try and
> > get to the
> > bottom
> > of it. Is this a question better asked on the mod_perl list?
> >
> > BTW - I'm not using PerlFreshRestart
 
> Not sure if this is the reason, but I wonder if you are using
> thread-enabled Perl. The reason I ask is that I see a call to finfo(),
> and under threaded Perl (on Solaris, not Linux though) I was getting
> an intermittent Perl error about not being able to "upgrade this kind of
> scalar".
> These errors were produced by calls to $r->finfo() in Mason/ApacheHandler.pm
> I wrapped them into eval() with a fallback to $r->filename()
> and the problem disappeared. I suggest you try replacing calls to finfo()
> with filename() and see what happens (it certainly may degrade the
> performance).


It seems Harry was correct with this, I applied the following patch
supplied by Doug on the mod_perl list and the segfaults have gone away.
We're not using threaded perl by the way.

On another note, our Mason driven sites have been getting well over 1
million page views a day this week (main one is UEFA Champions League
Fantasy Football - http://uclff.ismgames.com) and the performance has
been great :-)


On Sat, 9 Sep 2000, Shane Adams wrote:

> #7  0x80894de in XS_Apache_finfo (cv=0x8207410) at Apache.xs:1844

i haven't tried to reproduce this, but suspect a bug in $r->finfo which
the patch below should workaround.

 --- lib/HTML/Mason/ApacheHandler.pm~    Thu Aug 24 22:42:51 2000
+++ lib/HTML/Mason/ApacheHandler.pm     Mon Sep 11 11:43:02 2000
@@ -531,7 +531,7 @@
     # If filename is a directory, then either decline or simply reset
     # the content type, depending on the value of decline_dirs.
     #
-    if (-d $r->finfo) {
+    if (-d $r->filename) {
        if ($self->decline_dirs) {
            return DECLINED;
        } else {
@@ -544,7 +544,7 @@
     # (mainly for dhandlers).
     #
     my $pathname = $r->filename;
-    $pathname .= $r->path_info unless -f $r->finfo;
+    $pathname .= $r->path_info unless -f _;
 
     #
     # Compute the component path via the resolver.
@@ -555,7 +555,7 @@
     #
     # Decline if file does not pass top level predicate.
     #
-    if (-f $r->finfo and defined($self->{top_level_predicate})) {
+    if (-f _ and defined($self->{top_level_predicate})) {
        return NOT_FOUND unless
$self->{top_level_predicate}->($r->filename);
     }

===


the rest of The Pile (a partial mailing list archive)

doom@kzsu.stanford.edu