Try setting in httpd.conf: PerlInterpStart 1 PerlInterpMax 1 PerlInterpMinSpare 1 PerlInterpMaxSpare 1
Jacek ----- Original Message ----- From: Andrew McLaren To: modperl@perl.apache.org Sent: Friday, September 03, 2010 4:33 AM Subject: [DBI] msvcrt.dll issues when running in an XP environment This is my first delve into Apache on Windows (XP Pro SP3), so potentially it's a dumb user issue. The webserver is Apache 2.2 (2.2.16) based, running mod_perl, with a Postgre database buried otherneath accessed via DBI and DBD::Pg (have also tried DBD::ODBC but that caused other dll problems so won't go there). The mod_perl handler is using the Apache2:RequestRec and IO modules, and running Apache::DBI to manage persistent DB connections. It is also using Log4perl, primarily as a debugging resource while the handler is developed, and some basic XML packages to decode the incoming data. Once I got past a trivial mod_perl handler to verify that there was a basic Apache server running, I've been plagued with stability issues. Sometimes httd crashes (more often than not with msvcrt.dll expections), but other times it just hangs. This has got to the state where just moving whitespace around in the mod_perl handler changes how it behaves. If it's crashing httpd.exe with msvcrt.dll exceptions, simply adding or removing blank lines or comments can cure the problem! But as soon as there are any code changes to fix a real problem, the msvcrt problems can recur, or sometimes httpd.exe just 'expires' with no information at all. At present httpd is running OK from a console window, but any attempt to start it as a service (httpd -k start) hangs with no information at all. I'm running out of hair. All I am certain about is that it's related to my mod_perl handler (and by default its associated packages). The handler logic is running with warnings enabled, strict in force, and have also run this under an external shell with no issues flagged. From various notes in here and elsewhere on the net, there are issues related to msvcrt.dll, and particularly problems due to inconsistancies between the versions used to build Apache and mod_perl. Based on this, I've deinstalled Apache, and reinstalled with a fresh copy of the Apache binaries from the ASF (2.2.16), and mod_perl from theoryx5 (which I understand is consistent with the ASF base release). This resulted in no perceptible changes in stability. While I'm writing this I've clicked there are no doubt a number of other Perl packages that are also XS based, and potentially have the same consistency issues, such as DBD::Pg for Postgre (maybe even Perl itself?). Other than mod_perl, everything else I had been using was from my vanilla Perl installation, and hadn't really given much thought to where packages were sourced from (my PPM repositories include ActiveState, Bribes and Roth). I did have 1.45 DBD::Pg installed which was crashing when a second DBI connect was attempted, so had upgraded this to V2.01 from pgfoundry.org. I've seen that theoryx5 has a 1.45 DBD::Pg package there, so that is something to try. Initially I had thought that Log4perl could have been the problem, but I had earlier removed all references to that but the problems remained. However, its still potentially one of many. Any advice on where to from here? I'll definitely try reverting DBD::Pg back to the theoryx5 1.45 version (and should do DBI at the same time), but what of the multitude of other packages, such as Log4Perl, or even packages that ship with Perl (I'm using 5.8.8 build 822). Just how paranoid do I need to be? Any other tips or ideas on getting any visibility into what httpd is doing when it starts - I've got the logging levels to debug, but this doesn't give any more detail than what modules are being loaded. Windows is a bit of a black box at the best of times... The other option is to bite the bullet, and port everything the other way (ie to Unix). When I started it seemed a trivial matter to add an Apache websever and some mod_perl to Windows - now I suspect it would have been a lot quicker to go what appeared the longer route and move the rest of the application to Unix. Any advice, ideas or thoughts appreciated. Thanks and regards - Andrew
