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:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 2:11 PM To: JY - June Young Cc: [EMAIL PROTECTED] 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.
