Re: Child keeps seg faulting
> > I have the following config: Solaris 2.7, perl 5.6, php4 and mod_perl > 1.25 compiled > > statically into Apache 1.3.19. This exact same config works flawlessly > on several > > Suse machines and a few Red Hat machines. After building and testing > the server, I > > get the following error when trying to execute the printenv cgi script > that comes > > with Apache: > > [Wed Apr 25 14:58:04 2001] [notice] Apache/1.3.19 (Unix) PHP/4.0.4pl1 > mod_perl/1.25 \ > > configured -- resuming normal operations > > [Wed Apr 25 14:58:07 2001] [notice] child pid 11107 exit signal > Segmentation Fault (11) > > [Wed Apr 25 14:59:06 2001] [notice] child pid 11108 exit signal > Segmentation Fault (11) > > > > Anyone have any ideas? > >Yes, read the SUPPORT file in the source dist and follow the prescribed >steps to report a bug. I have this problem too. I compiled from the SRPM of Apache and mod_perl from Red Hat 7.1 and installed them on my Red Hat 6.2. Sorry that I have forgotten the details of my installation. [Wed Apr 25 15:25:44 2001] [notice] child pid 11990 exit signal Segmentation fault (11)
Re: mod_perl DSO leaking on restart?
Same here. I did a few graceful restarts and the usage jumped to 80M from 10M... Then I "apachectl stop" and "apachectl start" to get a clean restart, it works fine. I am new to this list. Maybe this problem has been addressed... At 10:40 PM 2001/4/25 -0400, Philip Mak wrote: >On Thu, 26 Apr 2001, Stas Bekman wrote: > > > > There is also the strange case of mod_perl leaking memory on graceful > > > restarts when compiled as DSO. But I don't feel like getting into > > > this one quite yet. > >Hmm. My httpd was using 20 MB. I did "apachectl graceful" ten times, and >the usage jumped to 24 MB. Then I did "apachectl graceful" another ten >times, and the usage jumped to 29 MB. > >I guess that's the reason (or one of them) that my httpd grows bigger and >bigger as time passes. My mod_perl is a DSO (I run two copies of httpd, >one without mod_perl and one with; I set it up as a DSO since this way I >only need one executable). Should I recompile it statically linked? > >-Philip Mak ([EMAIL PROTECTED])
single server mode problem
Hello, we are trying to do some debugging in single server mode, but we have problems. We tried running the httpd daemon from the command line: > .../apache/bin/httpd -X & or configuring the http.conf like this: MinSpareServers 1 MaxSpareServers 0 StartServers 1 MaxClients 1 and starting the server normally with > .../apache/bin/apachectl start In both cases we have the same problem: The CGI runs up to a certain point and then stops, like waiting for something (we can follow this with tail -f .../error_log), the browser waits for more data to come (that will never come). But if we press STOP on the browser, the CGI resumes/continues to run and goes to the end. It seems that this happens only if the CGI is doing a considerable amount of work, if it ends quickly we don't have problems. It also looks like it always stops on a print statement, maybe there is some problem flushing the buffer. Any idea about what is wrong here? Thanks, Giacomo
Re: apache::registry + use strict curiosity
that's no apache::registry. that's perl
there are big guns here who can answer
your questions but it am not one of them.
On Thu, Apr 26, 2001 at 02:25:17PM -0700, Eric Kolve wrote:
> I found something a bit curious that I was wondering if someone could
> explain. I have the following apache::registry script I called test.reg:
>
> #!/usr/bin/perl
>
> use strict;
> if($test){
> # do stuff
> }
>
>
> print qq|HTTP/1.1 200 OK\r\n|;
> print "HELLO WORLD\n\n";
>
>
> I ran my server in single-user mode (httpd -X) and requested the page
> which causes an internal server error because I didn't declare '$test'.
> I next commented out the three conditional lines:
>
> #if($test){
> # do stuff
> #}
>
> Then requested the page a second time, which executed just fine. I
> uncommented those three lines and requested the page a third time, which
> strangely enough actually works. Registry stats pages to see if they
> change and recompiles pages I believe. So I am wondering why isn't an
> exception raised on the third request about not declaring '$test'? Did
> the first request put '$test' in the symbol table?
>
> thanks,
>
> --eric
Re: apache::registry + use strict curiosity
Yes, exactly. After the first run, $test got an entry in the symbol
table. Not usually an issue in CGI perl. =)
[EMAIL PROTECTED] (Eric Kolve) wrote:
>I found something a bit curious that I was wondering if someone could
>explain. I have the following apache::registry script I called test.reg:
>
>#!/usr/bin/perl
>
>use strict;
>if($test){
># do stuff
>}
>
>
>print qq|HTTP/1.1 200 OK\r\n|;
>print "HELLO WORLD\n\n";
>
>
>I ran my server in single-user mode (httpd -X) and requested the page
>which causes an internal server error because I didn't declare '$test'.
>I next commented out the three conditional lines:
>
>#if($test){
># do stuff
>#}
>
>Then requested the page a second time, which executed just fine. I
>uncommented those three lines and requested the page a third time, which
>strangely enough actually works. Registry stats pages to see if they
>change and recompiles pages I believe. So I am wondering why isn't an
>exception raised on the third request about not declaring '$test'? Did
>the first request put '$test' in the symbol table?
------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED]The Math Forum
apache::registry + use strict curiosity
I found something a bit curious that I was wondering if someone could
explain. I have the following apache::registry script I called test.reg:
#!/usr/bin/perl
use strict;
if($test){
# do stuff
}
print qq|HTTP/1.1 200 OK\r\n|;
print "HELLO WORLD\n\n";
I ran my server in single-user mode (httpd -X) and requested the page
which causes an internal server error because I didn't declare '$test'.
I next commented out the three conditional lines:
#if($test){
# do stuff
#}
Then requested the page a second time, which executed just fine. I
uncommented those three lines and requested the page a third time, which
strangely enough actually works. Registry stats pages to see if they
change and recompiles pages I believe. So I am wondering why isn't an
exception raised on the third request about not declaring '$test'? Did
the first request put '$test' in the symbol table?
thanks,
--eric
Re: problem compiling under win98
On Thu, 26 Apr 2001 [EMAIL PROTECTED] wrote: > ok it compiles from vc+ ! > > (i had to drop a void apachecore.lib file in the vc6 file list, that pointed > to a strange > > c:\unzipped\ap\apache-1.3\src\release\apachecore.lib . suppose some one > forgot it here. That line has to be changed anyway, to tell Visual Studio where apachecore.lib is (running Makefile.PL with APACHE_SRC specified will change this line for you). > and when adding directive in httpd.conf and running i have the reassuring > line : > > Apache/ 1.3.19 (win32) mod_perl/1.25 PHP/4.0.4pl1 running... > > about the test i type nmake test in c:\mod_perl-1.25 dir from comman window > and got this line > > makefile(533) fatal error U1035: syntax error : expected ':' or '=' > separator stop. This is a problem in your \Perl\lib\ExtUtils\MM_Unix.pm - it thinks that Win9x uses dmake, and not nmake. You'll get the same error building some other XS-based modules. > i don't know where is the test file is and if i should test at this point The test suite is run with nmake test after building. But, as you noticed, you have to fix the make error first. You might also be able to run the tests as perl -Mblib t\TEST.win32 > note that it > continues to fail from perl > > here is the output of perl makefile.pl after the changes suggested : > > (maybe some perl bad installation) [ ... ] These errors, and the make error above, don't really indicate a bad perl installation - ActivePerl has a few things set in \Perl\lib\ExtUtils\*.pm that are NT-specific. Check the perl win32-porters list on ActiveState's site for a recent thread on how to fix things. best regards, randy kobes
Re: problem compiling under win98
Hi ! ok it compiles from vc+ ! (i had to drop a void apachecore.lib file in the vc6 file list, that pointed to a strange c:\unzipped\ap\apache-1.3\src\release\apachecore.lib . suppose some one forgot it here. and when adding directive in httpd.conf and running i have the reassuring line : Apache/ 1.3.19 (win32) mod_perl/1.25 PHP/4.0.4pl1 running... about the test i type nmake test in c:\mod_perl-1.25 dir from comman window and got this line makefile(533) fatal error U1035: syntax error : expected ':' or '=' separator stop. i don't know where is the test file is and if i should test at this point thanks a lot for your help anyway. note that it continues to fail from perl here is the output of perl makefile.pl after the changes suggested : (maybe some perl bad installation) * Commande ou nom de fichier incorrect Commande ou nom de fichier incorrect Unable to find a perl 5 (by these names: C:\Perl\bin\Perl.exe miniperl perl perl5 perl5.6.0, in these dirs: C:\Program Files\TextPad 4\ C:\ELJ-WIN32\SMALLEIFFEL\BIN C:\ELJ-WIN32\LCC\BIN C:\WINDOWS C:\WINDOWS\COMMAND C:\PERL\BIN\ C:\PROGRA~1\PANDAS~1\PANDAA~1.0 C:\Perl\bin) Writing Makefile for Apache Writing Makefile for Apache::Connection Writing Makefile for Apache::Constants Writing Makefile for Apache::File Commande ou nom de fichier incorrect Running '..\0 -IC:\Perl\lib C:\Perl\lib\ExtUtils\xsubpp -v 2>&1' exits with status 16777215 at (eval 121) line 17. Commande ou nom de fichier incorrect Running '..\0 C:\Perl\lib\ExtUtils\xsubpp temp000 2>&1' exits with status 16777215 at (eval 121) line 43. Writing Makefile for Apache::Leak Writing Makefile for Apache::Log Writing Makefile for Apache::ModuleConfig Writing Makefile for Apache::PerlRunXS Writing Makefile for Apache::Server Writing Makefile for Apache::Symbol Writing Makefile for Apache::Table Writing Makefile for Apache::URI Writing Makefile for Apache::Util Writing Makefile for mod_perl Beginning with version 1.3.15, Apache uses a different convention for Win32 module names. Correspondingly, the name of the mod_perl module built here has been changed from ApacheModulePerl.dll to mod_perl.so. Please see INSTALL.win32 for further details. - Original Message - From: "Randy Kobes" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, April 26, 2001 6:00 PM Subject: Re: problem compiling under win98 > On Thu, 26 Apr 2001 [EMAIL PROTECTED] wrote: > > > i have succesfully compiled apache 1_3.19 under win 98 with vc6 > > and dsw project > > > > I'm trying to compile mod_perl 1_25 under windows 98 the same way > > i downloaded the source 1_25 and found the modperl.dsp > > for vc++ compiling > > i followed the install.win32 notes but when compiling there are > > missing files : > [ ... ] > > c:\apache_1.3.19\src\include\ap_config.h(114) : fatal error C1083: > > Cannot open include file: 'os.h': No such file or directory > [ ... ] > > Apache_1.3.19 changed the way that the header os.h was included. > To fix this, if you're building mod_perl.so from Visual Studio, > include > C:\apache_1.3.19\src\os\win32 > as well as > C:\apache_1.3.19\src\include > in the list of include directories. If you're building this > from command line arguments, find the line in the mod_perl > top-level Makefile.PL > > s!(/D "WIN32")!/I "$apache_inc" /I "$perl_inc" $1!; > > and change this to (all on one line) > > s!(/D "WIN32")!/I "$apache_inc" /I "$apache_inc/../os/win32" > /I "$perl_inc" $1!; > > Whichever way you choose, does this then build OK? If so, > the tests might fail for a different reason, due to another > change in apache_1.3.19 in setting the relative server root > to the path of the apache binary. As a temporary fix, > in t\docs\startup.pl and t\docs\rl.pl, find occurrences of > $Apache::Server::CWD > and change this to the path to the mod_perl build directory > (eg, "C:\mod_perl-1.25"). > > best regards, > randy kobes >
Re: [OT] mod_perl 2 question...
Not OT at all... On Thu, Apr 26, 2001 at 06:24:41PM +0200, Issac Goldstand wrote: > > Can any of the mod_perl 2 people provide some feedbak on this, as I'm > sure you guys have looked at this much deeper than I have. Well, I'm not a "mod_perl 2" person, but I can say that PerlInterpScope (it's been renamed) merely lets you control whether interpreter threads are allocated per HTTP request/subrequest/handler call/connection, not associate an interp with a client. The 'connection' option (I think) looks like it's mostly for more session oriented protocols, the FM (modperl_2.0.pod) mentions ftp. If you wanted to muck about in C or with your own protocol handler, you could take some session ID (cookie, URL, say, just not the client's IP address) and direct it to a particular thread, but... You probably don't want intepreters devoted to individual clients whether they be in threads or in processes. Waste of good memory, that. It might help in rare circumstances with keepalives (pure conjecture here), but keepalives don't guarantee that the client will only make one connection. Without keepalives on, most popular browsers make multiple connections to the server and can keep several connections busy at once. That's still technically possible with keepalives, though I don't know if any browsers try to open multiple kept-alive connections intentionally (though they can if a server has more than one IP & host name). Closer to what you're thinking of are the 'solar' variables Doug mentions wistfully. But unless you back the in-memory store to a disk or something, you lose on server shutdown, which takes you back to conventional session management techniques, although it does look like you could share some fewer number of database connections or open filehandles between your threads to do this using Doug's wrappers around Apache's memory pools. - Barrie
Re: problem compiling under win98
On Thu, 26 Apr 2001 [EMAIL PROTECTED] wrote: > i have succesfully compiled apache 1_3.19 under win 98 with vc6 > and dsw project > > I'm trying to compile mod_perl 1_25 under windows 98 the same way > i downloaded the source 1_25 and found the modperl.dsp > for vc++ compiling > i followed the install.win32 notes but when compiling there are > missing files : [ ... ] > c:\apache_1.3.19\src\include\ap_config.h(114) : fatal error C1083: > Cannot open include file: 'os.h': No such file or directory [ ... ] Apache_1.3.19 changed the way that the header os.h was included. To fix this, if you're building mod_perl.so from Visual Studio, include C:\apache_1.3.19\src\os\win32 as well as C:\apache_1.3.19\src\include in the list of include directories. If you're building this from command line arguments, find the line in the mod_perl top-level Makefile.PL s!(/D "WIN32")!/I "$apache_inc" /I "$perl_inc" $1!; and change this to (all on one line) s!(/D "WIN32")!/I "$apache_inc" /I "$apache_inc/../os/win32" /I "$perl_inc" $1!; Whichever way you choose, does this then build OK? If so, the tests might fail for a different reason, due to another change in apache_1.3.19 in setting the relative server root to the path of the apache binary. As a temporary fix, in t\docs\startup.pl and t\docs\rl.pl, find occurrences of $Apache::Server::CWD and change this to the path to the mod_perl build directory (eg, "C:\mod_perl-1.25"). best regards, randy kobes
[OT] mod_perl 2 question...
I was just looking at Doug's overview of mod_perl 2, and was specifically intrigued by the PerlInterpLifetime directive, which got me sorta excited. It would appear to me, based on that, that by setting PerlInterpretLifetime connection, you could have a good chance at getting good persistant "session"s with any HTTP/1.1 client, with no more than plain ol' global variables. Moreso, you can see which is the first request easily just by checking defined($someglobalvariable) - or so it would appear... Can any of the mod_perl 2 people provide some feedbak on this, as I'm sure you guys have looked at this much deeper than I have. Thanks, Issac Internet is a wonderful mechanism for making a fool ofyourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint:7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: Is this startup.pl ok?
Philip Mak <[EMAIL PROTECTED]> writes: > I thought it was shared, because under top, "SHARE" was almost as big as > "RSS". Before Stas starts laying into me for misleading inaccuracy, take a look at the guide: http://perl.apache.org/guide/ There's LOTS of good stuff in there on shareabiliy. If your processes start at 10M, then grow to 80M, that memory is probably _not_ shared. Unless you're mapping in some shared memory or something. -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Interim CTO, web server farms, technical strategy
Re: template toolkit compile test problems
Hi there, On Tue, 24 Apr 2001, Ruslan V. Sulakov wrote: > What is PerlFixupHandler for? > Whats the difference of PerlFixupHandler and PerlTransHandler? The Eagle Book: "Writing Apache Modules with Perl and C", ISBN 1-56592-567-X, by Lincoln Stein and Doug MacEachern. It is available from O'Reilley (www.oreilly.com) and of course from Jubilee Office Supplies (www.jubileegroup.co.uk). Some of it might be available to you on-line. Stas Bekman's mod_perl Guide: http://perl.apache.org/guide/ 73, Ged.
Re: Is this startup.pl ok?
On 26 Apr 2001, Dave Hodgkinson wrote: > > As time goes on, these processes' memory usage grows and grows. Right now > > they're 20 MB (uptime 2 days). When I rebooted the machine two days ago, > > they were using 80 MB each (shared memory, though). MaxRequestsPerChild is > > set to 200. > > What operating system? Apache/1.3.12 (Unix) mod_perl/1.24 perl 5.005_03 Linux 2.2.14-5.0; Red Hat Linux release 6.2 (Zoot) > I'd be inclined to stuff a lot more of the generic modules you use > (CGI, Template Toolkit, URI, Date modules) into startup.pl. The more > the merrier. Ok. I didn't think of that. > If a process starts at 10M and grows to 80M that's 70M per process, > _unshared_ for sure. Not good. I thought it was shared, because under top, "SHARE" was almost as big as "RSS". -Philip Mak ([EMAIL PROTECTED])
Re: readdir()
Thanks everyone. I'll try backgrading to glibc 2.1. Does anyone know if the problem is still present in Perl 5.6.1? Lincoln Andrew Ho writes: > Hello, > > LS>Perl 5.6.0 breaks the readdir() function when running under mod_perl. > LS>This is with the most recent versions of Apache and mod_perl, as well > LS>as with older versions. I see the same problem reported in the > LS>mailing list going back to December 2000, but no hint of a > LS>resolution. Is there any fix? > > Are there references to the problem reports? readdir() works fine for me > with Apache 1.3.19, mod_perl 1.25, and Perl 5.6.0 on Solaris 2.7 (x86). > > Humbly, > > Andrew > > -- > Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] > Engineer [EMAIL PROTECTED] Voice 650-930-9062 > Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 > -- -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY NOW HIRING BIOINFORMATICS POSTDOCTORAL FELLOWS AND PROGRAMMERS. PLEASE WRITE FOR DETAILS.
Re: template toolkit compile test problems
On Tue, 24 Apr 2001, Ruslan V. Sulakov wrote: > What is PerlFixupHandler for? > Whats the difference of PerlFixupHandler and PerlTransHandler? FAQ: Trans: http://modperl.com/book/chapters/ch7.html#The_URI_Translation_Phase Fixup: http://modperl.com/book/chapters/ch7.html#Customizing_the_Fixup_Phase _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: template toolkit compile test problems
What is PerlFixupHandler for? Whats the difference of PerlFixupHandler and PerlTransHandler? Thanks, Ruslan
Re: mod_perl DSO leaking on restart?
On Wed, Apr 25, 2001 at 10:40:12PM -0400, Philip Mak wrote: > On Thu, 26 Apr 2001, Stas Bekman wrote: > > > > There is also the strange case of mod_perl leaking memory on graceful > > > restarts when compiled as DSO. But I don't feel like getting into > > > this one quite yet. > > Hmm. My httpd was using 20 MB. I did "apachectl graceful" ten times, and > the usage jumped to 24 MB. Then I did "apachectl graceful" another ten > times, and the usage jumped to 29 MB. > > I guess that's the reason (or one of them) that my httpd grows bigger and > bigger as time passes. My mod_perl is a DSO (I run two copies of httpd, > one without mod_perl and one with; I set it up as a DSO since this way I > only need one executable). Should I recompile it statically linked? I had the same problems, after linking modperl statically into httpd the leaks disappeared. -- Jens-Uwe Mager HELIOS Software GmbH Steinriede 3 30827 Garbsen Germany Phone: +49 5131 709320 FAX:+49 5131 709325 Internet: [EMAIL PROTECTED]
IPC:Open3 does not work under mod_perl/1.25, perl5.6.0?
My program, which worked under mod_perl/1.23 and perl5.500502 does not
work anymore:
I fork a program with Open3, send it some input and catch its output.
The output is OK, but the program does not get the input:
...
my $cgi_in = Apache::File->new;
my $cgi_out = Apache::File->new;
my $cgi_error = Apache::File->new;
...
my $child = open3 ($cgi_in, $cgi_out, $cgi_error, $filename);
...
if ($post) {
my $len = $r->header_in ('Content-length');
while ($len) {
my $content;
my $size = min ($len, 4096);
$r->read ($content, $size);
$r->log->debug ("content: <$content>");
print $cgi_in $content; # this statement does not work
$len -= $size;
}
}
close ($cgi_in);
...
IPC:Open3 works on my system, and I can print to files from my mod_perl
script. I tried the syswrite call, too.
Any comments, solutions?
Thanx
Peter
Re: Is this startup.pl ok?
Philip Mak <[EMAIL PROTECTED]> writes: > My Apache with modperl is acting weird with respect to memory usage. > > When it first starts up, each process uses 10 MB of memory. > > As time goes on, these processes' memory usage grows and grows. Right now > they're 20 MB (uptime 2 days). When I rebooted the machine two days ago, > they were using 80 MB each (shared memory, though). MaxRequestsPerChild is > set to 200. What operating system? I'd be inclined to stuff a lot more of the generic modules you use (CGI, Template Toolkit, URI, Date modules) into startup.pl. The more the merrier. If a process starts at 10M and grows to 80M that's 70M per process, _unshared_ for sure. Not good. -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Interim CTO, web server farms, technical strategy
