Re: bug: calling setlocale(LC_ALL,)more than once crashes httpd with mod_perl
Vlad Harchev wrote: >>> When using the following script under mod_perl, each httpd process crashes on >>>the 2nd request to execute this script. >>> >>>#!/usr/bin/perl >>>use strict; use POSIX qw(locale_h); >>>setlocale(LC_ALL,'en_US.utf8'); >>>print "Expires: 1 Jan 1970\nContent-Type: text/html\n\nHi"; >>>- >>> This crashes if instead of 'en_US.utf8' one uses any other utf8 locale that >>>is available in the system. If one uses locale with single-byte encoding (e.g. >>>'en_US.ascii' or 'ru_RU.koi8r') it doesn't crash httpd. (I didn't try >>>other multibyte encodings beside utf8). >>> >>> If one uses LC_COLLATE instead of LC_ALL, it doesn't crash for any locale (I >>>didn't try other locale categories). (The httpd server is started under >>>locale 'ru_RU.koi8r' - a single-byte locale). >>> >>> I'm using mod_perl on RH72 for x86, versions of the relevant software: >>>perl-5.6.0-17 >>>mod_perl-1.24_01-3 >>>glibc-2.2.4-19.3 >>>apache-1.3.20-16 >> >>I doubt it's a bug in mod_perl. Setting locale affects the lots of core >>things, so a simple test may not trigger the problem. >> >>BTW, if I remember correctly Perl 5.6.0 is not utf8-safe (or unicode in >>general), correct me if I'm wrong. Can you try the same with the latest >>bleadperl? (skip the 'make test' there is some problem in perl that I'm >>fixing now). 5.8.0 should be out in a month or so and it should work >>well with unicode. > > > Unfortunately, I don't have time for compiling and installing it.. > I hope somebody on this list who has already installed version of recent perl > will test the problem.. Confirmed as working with bleadperl (i.e the latest perl-5.7.3) Also confirmed as working with the stock 5.6.1 perl on linux. So I'd suggest to upgrade to 5.6.1 if possible as the safest step, before 5.8.0 is released. All tested with Apache/1.3.25-dev (Unix) mod_perl/1.26_01-dev but the non-cvs version should probably work the same way. __ 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
htaccess
Title: htaccess Hi All, I'm new at this and i'm trying to write my own custom htaccess file. Here is what i have written so far: - AuthUserFile /dev/null AuthGroupFile /dev/null RewriteEngine On RewriteCond %{HTTP_REFERER} !^http://www.myserver.com [NC] RewriteCond %{HTTP_REFERER} !^http://myserver.com [NC] RewriteRule /* http://www.myserver.com/error.mv [R,L] - My question is, instead of a RewriteRule that returns a page, how do i write it so it returns either A) nothing or, B) some text like "Not Found"? Paul Williams -- == http://www.StuckMic.com/america -- The American Code Remembering the attack on America http://www.StuckMic.com -- MIVA Powered Aviation and Air Traffic Control discussion and chat. http://www.WavSounds.com -- Thousands of funny wavs, fully searchable.
Lessons learned using PREFIX,LIB and UNINST=1 as root
LESSON: Don't do all 3 of the following for any core modules (unless you know you want the original version removed from the core install): a) remove old versions during install (using UNINST=1) while b) installing modules to an alternate location (using PREFIX=.../LIB=...) as c) root (or same user as the owner of the core installation) Any two alone should be safe, but all 3 can be hazardous to your sanity! STORY: I was having problems a couple of weeks ago getting mod_perl make test to run - both the test programs and apache itself were complaining about CGI.pm not being found. I tried modifying Makefile.PL and httpd.conf-dist and adding local.pl to t/conf to make it work again (which it did but wasn't necessary as it turns out). Well, today I found the source of all my problems...Doh! They were self inflicted. Apologies to all on the list for my getting annoyed (privately) that no-one else had had this problem, or had a clue as to how to fix it. I was using cpan to install modules as root, and had UNINST=1 set, which had the (designed) side effect of uninstalling CGI.pm from the core distribution when I installed the latest version into my alternate location. >From now on I'll leave the core install untouched, and install all my add-on modules as a non-root user just to be safe. Once I reinstalled perl (just re-ran last make install from source tree), the mod_perl test suite ran just fine (unmodified version 1.26). I also added PREFIX and LIB to my makepl_args.mod_perl file rather than having to remember to add them to the "perl Makefile.PL" line for future mod_perl builds. The thing that clued me into my problem was that CGI.pm is a core module (which I was reminded of by skimming thru the Programming Perl/camel book today). CGI.pm should therefore ALWAYS be available (safe assumption I suppose), and it wasn't in this case - so I had done something wrong. It didn't take long (about 5 seconds) to figure out WHY is wasn't in the core any longer. I've never seen anything warning against doing things this way (root, UNINST=1 AND PREFIX/LIB) (that I remember at least) so if this is already well-known and documented, please, make me $humble++, and enlighten me. I understand it - now - I'm just hoping it's an "obvious in hindsight only" type of thing. Thanks, Jim
Re: bug: calling setlocale(LC_ALL,) more than once crashes httpd with mod_perl
On Sun, 14 Apr 2002, Stas Bekman wrote: Hi, > Vlad Harchev wrote: > > Hi, > > > > When using the following script under mod_perl, each httpd process crashes on > > the 2nd request to execute this script. > > > > #!/usr/bin/perl > > use strict; use POSIX qw(locale_h); > > setlocale(LC_ALL,'en_US.utf8'); > > print "Expires: 1 Jan 1970\nContent-Type: text/html\n\nHi"; > > - > > This crashes if instead of 'en_US.utf8' one uses any other utf8 locale that > > is available in the system. If one uses locale with single-byte encoding (e.g. > > 'en_US.ascii' or 'ru_RU.koi8r') it doesn't crash httpd. (I didn't try > > other multibyte encodings beside utf8). > > > > If one uses LC_COLLATE instead of LC_ALL, it doesn't crash for any locale (I > > didn't try other locale categories). (The httpd server is started under > > locale 'ru_RU.koi8r' - a single-byte locale). > > > > I'm using mod_perl on RH72 for x86, versions of the relevant software: > > perl-5.6.0-17 > > mod_perl-1.24_01-3 > > glibc-2.2.4-19.3 > > apache-1.3.20-16 > > I doubt it's a bug in mod_perl. Setting locale affects the lots of core > things, so a simple test may not trigger the problem. > > BTW, if I remember correctly Perl 5.6.0 is not utf8-safe (or unicode in > general), correct me if I'm wrong. Can you try the same with the latest > bleadperl? (skip the 'make test' there is some problem in perl that I'm > fixing now). 5.8.0 should be out in a month or so and it should work > well with unicode. Unfortunately, I don't have time for compiling and installing it.. I hope somebody on this list who has already installed version of recent perl will test the problem.. > In any case, you should send a backtrace of the coredump according to > the SUPPORT file found in the mod_perl source distro. I'll try to find time for this - but most probably debug info is stripped and backtrace will be meaningless. Again I hope somebody with perl built with debug info unstripped will be able to find time to produce backtrace. Thanks! Best regards, -Vlad
Re: DSO on Solaris - child dies with seg fault
Sreeji K Das wrote: > Thanx for the reply. However, I had already read the > doc. and done everything mentioned there. I had > recompiled perl with -Ubincompat5005 as mentioned. Good then. I just wasn't sure. Hopefully someone with Solaris access/knowledge will be able to help you out, but see below. > I've attached some additional info., generated by > trussing the child, as it was being restarted: > $truss -ef -o ~/truss.out -r0,1,2 -w0,1,2 -p 26978 What's needed is the core dump backtrace, see http://perl.apache.org/preview/modperl-docs/dst_html/docs/1.0/guide/help.html#How_to_Report_Problems __ 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
Re: bug: calling setlocale(LC_ALL,)more than once crashes httpd with mod_perl
Vlad Harchev wrote: > Hi, > > When using the following script under mod_perl, each httpd process crashes on > the 2nd request to execute this script. > > #!/usr/bin/perl > use strict; use POSIX qw(locale_h); > setlocale(LC_ALL,'en_US.utf8'); > print "Expires: 1 Jan 1970\nContent-Type: text/html\n\nHi"; > - > This crashes if instead of 'en_US.utf8' one uses any other utf8 locale that > is available in the system. If one uses locale with single-byte encoding (e.g. > 'en_US.ascii' or 'ru_RU.koi8r') it doesn't crash httpd. (I didn't try > other multibyte encodings beside utf8). > > If one uses LC_COLLATE instead of LC_ALL, it doesn't crash for any locale (I > didn't try other locale categories). (The httpd server is started under > locale 'ru_RU.koi8r' - a single-byte locale). > > I'm using mod_perl on RH72 for x86, versions of the relevant software: > perl-5.6.0-17 > mod_perl-1.24_01-3 > glibc-2.2.4-19.3 > apache-1.3.20-16 I doubt it's a bug in mod_perl. Setting locale affects the lots of core things, so a simple test may not trigger the problem. BTW, if I remember correctly Perl 5.6.0 is not utf8-safe (or unicode in general), correct me if I'm wrong. Can you try the same with the latest bleadperl? (skip the 'make test' there is some problem in perl that I'm fixing now). 5.8.0 should be out in a month or so and it should work well with unicode. In any case, you should send a backtrace of the coredump according to the SUPPORT file found in the mod_perl source distro. __ 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
Re: DSO on Solaris - child dies with seg fault
Hi Stas, Thanx for the reply. However, I had already read the doc. and done everything mentioned there. I had recompiled perl with -Ubincompat5005 as mentioned. I've attached some additional info., generated by trussing the child, as it was being restarted: $truss -ef -o ~/truss.out -r0,1,2 -w0,1,2 -p 26978 Note: I have also tried setting ENV PERL_DESTRUCT_LEVEL to -1 and also to 2, but got the same results. Thanx for any help. Sreeji --- Stas Bekman <[EMAIL PROTECTED]> wrote: > Sreeji K Das wrote: > > Hi, > > > > I was trying to run mod_perl as DSO on Solaris. I > see > > the following line in the logs: > > > > [notice] child pid 24323 exit signal Segmentation > > Fault (11) > > > > This happens whenever I send a USR1 to the server > for > > restart. Also I see the same message whenever the > > child is about to exit (ie. after handling the > > prescribed no.of requests). > > > > Is DSO stable enough to be used under Solaris ? I > have > > searched through the archives & see differing > > opinions. > > > > Additional Info: > > > > > > $perl -V:uselargefiles -V:bincompat5005 > > uselargefiles='define'; > > bincompat5005='undef'; > > > > perl: 5.6.1, Apache: 1.3.23, mod_perl: 1.26 > > Using SunOS 5.6 Generic_105181-16 sun4u sparc > > SUNW,Ultra-80 > > > > I've compiled mod_perl with PERL_USELARGEFILES=0 > and > > USE_DSO. > > The above problem is repeatable with > PerlFreshRestart > > On and Off. > > > > Any clues ? > > > > Thanx > > Sreeji > > (BTW, make test has gone through w/o any errors) > > > > See if it helps > you:http://perl.apache.org/guide/install.html#When_DSO_can_be_Used > > > > __ > 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 > __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com 26978: accept(16, 0xEFFFE95C, 0xEFFFE97C) (sleeping...) 26978: signotifywait() = 16 26978: Received signal #16, SIGUSR1, in accept() [caught] 26978:siginfo: SIGUSR1 pid=26322 uid=300528 26978: lwp_sigredirect(1, SIGUSR1) = 0 26978: accept(16, 0xEFFFE95C, 0xEFFFE97C) Err#4 EINTR 26978: sigprocmask(SIG_SETMASK, 0xEF276450, 0x) = 0 26978: setcontext(0xEFFFE5A8) 26978: sigaction(SIGHUP, 0xEFFFE6D0, 0xEFFFE7D4) = 0 26978: sigaction(SIGUSR1, 0xEFFFE6D0, 0xEFFFE7D4) = 0 26978: write(2, " `", 1) = 1 26978: write(2, 0xEF547EE4, 20)= 20 26978: P e r l C h i l d E x i t H a n d l e r 26978: write(2, 0xEF51E8E3, 33)= 33 26978: ' p u s h _ h a n d l e r s ( ) s t a c k i s e m p t y 26978:\n 26978: write(2, 0xEF547EE4, 20)= 20 26978: P e r l C h i l d E x i t H a n d l e r 26978: write(2, 0xEF51E05A, 19)= 19 26978: h a n d l e r s r e t u r n e d 26978: write(2, " - 1\n", 3) = 3 26978: write(2, " r u n n i n g ", 8) = 8 26978: write(2, " 3", 1) = 1 26978: write(2, 0xEF51F95E, 16)= 16 26978: E N D b l o c k s f o r 26978: write(2, 0xEF547DCC, 13)= 13 26978: p e r l _ s h u t d o w n 26978: write(2, "\n", 1) = 1 26978: getcontext(0xEFFFE320) 26978: getcontext(0xEFFFE158) 26978: write(2, 0x00E90A80, 48)= 48 26978: T S T F o r m s s e r v e r p r o c e s s 2 6 9 7 8 s 26978: h u t t i n g d o w n . . .\n 26978: write(2, 0x013725C0, 40)= 40 26978: R e s e t t i n g c o n n e c t i o n t o d a t a b a s e 26978: @ s i g t e s t 26978: write(2, "\n", 1) = 1 26978: getcontext(0xEFFFE320) 26978: getcontext(0xEFFFE158) 26978: getcontext(0xEFFFE320) 26978: getcontext(0xEFFFE158) 26978: write(2, 0xEF51D770, 48)= 48 26978: d e s t r u c t i n g a n d f r e e i n g P e r l i n t 26978: e r p r e t e r ( l e v e l = 26978: write(2, " 0", 1) = 1 26978: write(2, " ) . . .", 4) = 4 26978: getcontext(0xEFFFE120) 26978: getcontext(0xEFFFDFE8) 26978: getcontext(0xEFFFE120) 26978: getcontext(0xEFFFE120) 26978: getcontext(0xEFFFE120) 26978: getcontext(0xEFFFE120) 26978: getcontext(0xEFFFE120) 26978: getcontext(0xEFFFE120) 26978: getcontext(0xEFFFE120) 26978: getcontext(0xEFFFDFE8) 26978: write(2, " o k\n", 3) =
bug: calling setlocale(LC_ALL,)more than once crashes httpd with mod_perl
Hi, When using the following script under mod_perl, each httpd process crashes on the 2nd request to execute this script. #!/usr/bin/perl use strict; use POSIX qw(locale_h); setlocale(LC_ALL,'en_US.utf8'); print "Expires: 1 Jan 1970\nContent-Type: text/html\n\nHi"; - This crashes if instead of 'en_US.utf8' one uses any other utf8 locale that is available in the system. If one uses locale with single-byte encoding (e.g. 'en_US.ascii' or 'ru_RU.koi8r') it doesn't crash httpd. (I didn't try other multibyte encodings beside utf8). If one uses LC_COLLATE instead of LC_ALL, it doesn't crash for any locale (I didn't try other locale categories). (The httpd server is started under locale 'ru_RU.koi8r' - a single-byte locale). I'm using mod_perl on RH72 for x86, versions of the relevant software: perl-5.6.0-17 mod_perl-1.24_01-3 glibc-2.2.4-19.3 apache-1.3.20-16 It seems it's a bug in mod_perl, since the following C program -- #include #include int main(int argc,char** argv) { setlocale(LC_ALL,"en_US.utf8"); printf("try 1\n"); setlocale(LC_ALL,"en_US.utf8"); printf("try 2\n"); setlocale(LC_ALL,"en_US.utf8"); printf("try 3\n"); return 0; } Works without crashing. Also, the following perl script: #!/usr/bin/perl use strict; use POSIX qw(locale_h); for(my $i=0;$i<10; ++$i) { setlocale(LC_ALL,'en_US.utf8'); } print "done\n"; Works without crashing too. Granted, LC_COLLATE it's enough for my scripts, so this bug is not fatal to me. Best regards, -Vlad