Loading ...
Sorry, an error occurred while loading the content.

puzzle of split() running under mod_perl

Expand Messages
  • JY - June Young
    Hi, We are running CSWS1.2 (based on Apache 1.3.6) on Open VMS V7.3-1 and CSWS_PERL V1.1 based on Mod_Perl V1.25. We have a function that changes the directory
    Message 1 of 4 , Jun 17, 2003
    • 0 Attachment
      Message
      Hi, 
       
      We are running CSWS1.2 (based on Apache 1.3.6) on Open VMS V7.3-1 and CSWS_PERL V1.1 based on Mod_Perl V1.25.
       
      We have a function that changes the directory format from Unix to VMS, and this function is used in almost every script of our CGIs. Whenever the CGI that invokes this function get requested twice, the server process dies after the page comes out.
      In a single threaded server, we get Fatel error in the error log file.
         Fatal VMS error (status=36) at ROOT$:[PERL5_006_01]VMS.C;2, line 802 during global destruction.
      In a multi threaded server, we get a notice in the error log file
         [notice] child pid ab26 exit signal Bad system call.
       
       
      We noticed that it is the regex argument of function split causes the problem.
      We took this split statement out into a simple CGI script, and that CGI script works fine in mod_perl. 
       
      After adding quotes outside of the regex of split function in sub VMSify, the error went away. We could not figure out why the statement bombs out in our VMSify function and why adding quotes fixed it.  The following are the test script and output in the browser.
       
      Thanks in advance for all helps.
       
      test.cgi
      *******************************
      use strict;
      print "content-type:text/html\n\n";
      print "<head></head><body>\n";
       

      Test();
       
      sub Test{
         foreach (@::INC) {
            VMSify($_);
         }
      }
       
      sub VMSify{
         my @subDirs;
         my $directory=uc(shift);
       
         $directory=~s/^\/|\/$//g;
            print "dir=$directory\n<br>";
      #   @subDirs=split("/\//",$directory);
         @subDirs=split(/\//,$directory);
         $directory=undef;
         if(defined $ENV{$subDirs[0]}){
            $directory=shift(@subDirs).':';
         }elsif(scalar(@subDirs)==1 && $subDirs[0] eq '.'){
            # Special case for current directory
            @subDirs=();
            $directory='[]';
         }
         if(scalar(@subDirs)){
            $directory.='[';
            $directory.=join('.',@subDirs);
            $directory.=']';
         }
         print "dir after=$directory\n<br>";
         return $directory;
      }
       
      *******************
      The output in the web brower is
      dir=DYM$DISK/DYMAX/PERL/DYLIB
      dir after=DYM$DISK:[DYMAX.PERL.DYLIB]
      dir=PERL_ROOT/LIB/VMS_AXP/5_6_1
      dir after=PERL_ROOT:[LIB.VMS_AXP.5_6_1]
      dir=PERL_ROOT/LIB
      dir after=PERL_ROOT:[LIB]
      dir=PERL_ROOT:[LIB.SITE_PERL.VMS_AXP]
      dir after=[PERL_ROOT:[LIB.SITE_PERL.VMS_AXP]]
      dir=PERL_ROOT:[LIB.SITE_PERL]
      dir after=[PERL_ROOT:[LIB.SITE_PERL]]
      dir=PERL_ROOT/LIB/SITE_PERL
      dir after=PERL_ROOT:[LIB.SITE_PERL]
      dir=.
      dir after=[]
      dir=APACHE$ROOT
      dir after=APACHE$ROOT:
      dir=APACHE$ROOT/LIB/PERL
      dir after=APACHE$ROOT:[LIB.PERL]
       
      June Young, Software Development                   bus: (902)422-1973 x144
      Dymaxion Research Ltd., 5515 Cogswell St.,      fax: (902)421-1267
      Halifax, Nova Scotia, B3J 1R2 Canada           mailto: JYoung@...
      http://www.dymaxion.ca
       
       
    • Raf
      Ok, before heading off for the evening, here s a guess which may be totally wrong. ... Main assumption ( this is buggy and not real apache/mod_perl ) - (as
      Message 2 of 4 , Jun 17, 2003
      • 0 Attachment
        Ok, before heading off for the evening, here's a guess which may be
        totally wrong.

        JY - June Young said:

        > We are running CSWS1.2 (based on Apache 1.3.6) on Open VMS V7.3-1 and
        > CSWS_PERL V1.1 based on Mod_Perl V1.25.

        Main assumption ( this is buggy and not real apache/mod_perl ) - (as buggy
        as compaq (on disk) bioses, and all the compaq hardware, I've ever used,
        with the exception of the Dec Alpha (which was DEC at the time)).

        > We have a function that changes the directory format from Unix to VMS,
        > and this function is used in almost every script of our CGIs. Whenever
        > the CGI that invokes this function get requested twice, the server
        > process dies after the page comes out.
        Only on the second request?


        > We noticed that it is the regex argument of function split causes the
        > problem.
        > We took this split statement out into a simple CGI script, and that CGI
        > script works fine in mod_perl.

        Not sure about the syntax, by the outermost symbols should become
        delimiters for your reg.exp. (ie the quotes in your case)

        > After adding quotes outside of the regex of split function in sub
        > VMSify, the error went away. We could not figure out why the statement
        > bombs out in our VMSify function and why adding quotes fixed it. The
        > following are the test script and output in the browser.

        Adding the "'s, simply makes it try and split on the symbol sequence "/\//"
        which doesn't exist in the string you're matching against, returning the
        whole string again. At least, that is my observed behaviour in 5.6.1. and
        the way I use them.

        My completely unsupported guess, which is what I'd look for given the
        circumstances, is this:

        1) Given that:
        i) The original script segfaults the apache-clone
        ii) Your little cgi doesn't segfault anything.

        2) Assuming:
        i) You're using "'s in your 'original' live script

        ii) The split is returning an array of size 1, containing the original
        string in an your 'original' live script (because of the "/\//").

        iii) Your test cgi script, as stated, is only trying to test out the SPLIT.

        iv) *the major assumption* You take this converted path on your vms
        system (as generated in step 2.ii) and are trying to access some 'real'
        file path with it / and open or stat or something.

        3) Results in: (Complete Assumption)

        i) The apache-'clone' segfaulting/throwing a fatal/exploding
        on some attempt to read this real file path, which 'wasn't'
        really split in your live application and is still a unix path.

        ii) Compaq do it again and it's all their fault.

        iii) On a second read of your mail, 'adding' the quotes may have done
        this in reverse somehow and may still lead to either avoiding a syscall
        to open/read/stat/whatever a real file path.



        Although this is based on lots of assumptions, I think it might explain
        the segfault, which was fixed by removing(or was it adding?) your quotes.
        My thought was that fixing the server crash (which is what you wanted to
        explain?) came out of your avoiding a system call with a weird path to a
        real file. I don't know VMS, so I'm assuming nasties. I'm probably 90%
        wrong and it's that 10% of hope (and hmmm.. the "I'd look 'there' factor")
        which I offer you. Hmmm. I'd also look at unclearly scroped variables
        which remain persistent between hits (given your two hit problem - if that
        really is the case).

        Might help, who knows? Not I.

        Byebye.
      • JY - June Young
        Hi, Raf, Yes, the server does not die on the first time request. My original code does not have quotes and adding quotes removed the error. As you expected,
        Message 3 of 4 , Jun 17, 2003
        • 0 Attachment
          Hi, Raf,

          Yes, the server does not die on the first time request.

          My original code does not have quotes and adding quotes removed the
          error.

          As you expected, the function is used to add path to files for
          dynamically 'require' test version of *.pl in our CGI, but my test.cgi
          has not gone that far yet. Just the path conversion itself bombs the
          server, and what interesting is that the CGI results the same outputs
          with/without double quotes on the regexp. The print of the "dir after="
          shows that split correctly parsed the input string. The only difference
          is that the server dies upon global destruction?

          As a matter of fact, I am very confused by the error message of "global
          destruction". When does global destruction happen in mod_perl? Does my
          code causes server process die and then the process tries to do "global
          destruction" ? Or "global destruction" at some stage causes the process
          die. I thought mod_perl provide persistent environment, and no "global
          destruction" should happen until a process served enough requests and
          reached the end of lifecycle.

          Thanks,

          June

          -----Original Message-----
          From: Raf [mailto:rafiq@...]
          Sent: Tuesday, June 17, 2003 2:11 PM
          To: JY - June Young
          Cc: modperl@...
          Subject: Re: puzzle of split() running under mod_perl


          Ok, before heading off for the evening, here's a guess which may be
          totally wrong.

          JY - June Young said:

          > We are running CSWS1.2 (based on Apache 1.3.6) on Open VMS V7.3-1 and
          > CSWS_PERL V1.1 based on Mod_Perl V1.25.

          Main assumption ( this is buggy and not real apache/mod_perl ) - (as
          buggy as compaq (on disk) bioses, and all the compaq hardware, I've ever
          used, with the exception of the Dec Alpha (which was DEC at the time)).

          > We have a function that changes the directory format from Unix to VMS,

          > and this function is used in almost every script of our CGIs. Whenever

          > the CGI that invokes this function get requested twice, the server
          > process dies after the page comes out.
          Only on the second request?


          > We noticed that it is the regex argument of function split causes the
          > problem. We took this split statement out into a simple CGI script,
          > and that CGI script works fine in mod_perl.

          Not sure about the syntax, by the outermost symbols should become
          delimiters for your reg.exp. (ie the quotes in your case)

          > After adding quotes outside of the regex of split function in sub
          > VMSify, the error went away. We could not figure out why the statement

          > bombs out in our VMSify function and why adding quotes fixed it. The
          > following are the test script and output in the browser.

          Adding the "'s, simply makes it try and split on the symbol sequence
          "/\//" which doesn't exist in the string you're matching against,
          returning the whole string again. At least, that is my observed
          behaviour in 5.6.1. and the way I use them.

          My completely unsupported guess, which is what I'd look for given the
          circumstances, is this:

          1) Given that:
          i) The original script segfaults the apache-clone
          ii) Your little cgi doesn't segfault anything.

          2) Assuming:
          i) You're using "'s in your 'original' live script

          ii) The split is returning an array of size 1, containing the original
          string in an your 'original' live script (because of the "/\//").

          iii) Your test cgi script, as stated, is only trying to test out the
          SPLIT.

          iv) *the major assumption* You take this converted path on your vms
          system (as generated in step 2.ii) and are trying to access some 'real'
          file path with it / and open or stat or something.

          3) Results in: (Complete Assumption)

          i) The apache-'clone' segfaulting/throwing a fatal/exploding
          on some attempt to read this real file path, which 'wasn't'
          really split in your live application and is still a unix path.

          ii) Compaq do it again and it's all their fault.

          iii) On a second read of your mail, 'adding' the quotes may have done
          this in reverse somehow and may still lead to either avoiding a syscall
          to open/read/stat/whatever a real file path.



          Although this is based on lots of assumptions, I think it might explain
          the segfault, which was fixed by removing(or was it adding?) your
          quotes.
          My thought was that fixing the server crash (which is what you wanted to
          explain?) came out of your avoiding a system call with a weird path to a
          real file. I don't know VMS, so I'm assuming nasties. I'm probably 90%
          wrong and it's that 10% of hope (and hmmm.. the "I'd look 'there'
          factor") which I offer you. Hmmm. I'd also look at unclearly scroped
          variables which remain persistent between hits (given your two hit
          problem - if that really is the case).

          Might help, who knows? Not I.

          Byebye.
        • Raf
          Hi June, ... My understanding was that it happend with a child process exiting after it hit its max requests .. of if you shutdown. What I might try if you re
          Message 4 of 4 , Jun 18, 2003
          • 0 Attachment
            Hi June,

            JY - June Young said:

            > with/without double quotes on the regexp. The print of the "dir after="
            > shows that split correctly parsed the input string. The only difference
            > is that the server dies upon global destruction?
            >
            > As a matter of fact, I am very confused by the error message of "global
            > destruction". When does global destruction happen in mod_perl? Does my
            > code causes server process die and then the process tries to do "global
            > destruction" ? Or "global destruction" at some stage causes the process
            > die. I thought mod_perl provide persistent environment, and no "global
            > destruction" should happen until a process served enough requests and
            > reached the end of lifecycle.

            My understanding was that it happend with a child process exiting after it
            hit its max requests .. of if you shutdown. What I might try if you're
            really curious is trying to run it through strace or truss (well your vms
            equivs) with httpd -X, unless someone else can give you an immediate
            answer, it often proved itself a useful approach. Might give you an idea
            of what is causing the process to die.

            Last night's enthusiasm has worn off. :)

            All the best.

            R.
          Your message has been successfully submitted and would be delivered to recipients shortly.