bug: calling setlocale(LC_ALL,name of any locale with utf8 charset)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 locale.h
#include stdlib.h
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;$i10; ++$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
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) = 3 26978: Incurred fault #6, FLTBOUNDS %pc = 0xEF1A3CFC 26978:siginfo: SIGSEGV SEGV_MAPERR addr=0xEF1A3CFC
Re: bug: calling setlocale(LC_ALL,name of any locale with utf8 charset)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
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,name of any locale with utf8charset) 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
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
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.
cvs commit: modperl STATUS
stas02/04/14 10:25:03 Modified:.STATUS Log: need to resolve the URI/LWP bad combinations issue. Revision ChangesPath 1.15 +10 -1 modperl/STATUS Index: STATUS === RCS file: /home/cvs/modperl/STATUS,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- STATUS2 Apr 2002 15:10:02 - 1.14 +++ STATUS14 Apr 2002 17:25:03 - 1.15 -1,5 +1,5 mod_perl 1.3 STATUS: - Last modified at [$Date: 2002/04/02 15:10:02 $] + Last modified at [$Date: 2002/04/14 17:25:03 $] Release: -18,6 +18,15 Needs Patch or Further Investigation + +* make test fails when a wrong combination of URI and LWP are + installed. (e.g. lwp 5.64 and URI 1.09). LWP's Makefile.PL + requires the right URI version, but certain binary distributors + miss this requirement and distribute LWP without making a + dependency on the right version of the URI package +Report: many reports in the last year. +Status: ??? +Suggestion: require libwww-perl 5.64 and URI 1.1 * two identical directives in Perl configuration Report: http://marc.theaimsgroup.com/?l=apache-modperlm=97449481013350w=2
