[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

Re: [DBI] msvcrt.dll issues when running in an XP environment

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01CB4B3F.F18B4450
Content-Type: text/plain;
charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Try setting in httpd.conf:

PerlInterpStart 1
PerlInterpMax 1
PerlInterpMinSpare 1
PerlInterpMaxSpare 1

Jacek
----- Original Message -----=20
From: Andrew McLaren=20
To: modperl@perl.apache.org=20
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


------=_NextPart_000_000A_01CB4B3F.F18B4450
Content-Type: text/html;
charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable



charset=3Diso-8859-1">

RE: [DBI] msvcrt.dll issues when running in an XP environment

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01CB4D07.A09DD840
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit

Further to the earlier note, I have been and done the following;

Replaced DBI, DBD-Pg and Log-Log4perl with the packages from theoryx5
(1.59, 1.45 and 1.06 respectively), which should all be compatible
builds with the ASF Apache release. At this point httpd is starting
successfully, but I'm immediately having a different problem with
Postgre. This is not Apache related - a simple bit of standalone Perl to
connect to a database crashes Perl with an exception on an unknown
ModName. Not a lot of help there. I've reverted back to the pgfoundry
2.10 DBD-Pg package. This gives connectivity back to the database, but
immediately starts giving the msvcrt.dll errors when running under
Apache.

At the moment I'm at a bit of a Catch 22. I can't totally verify that
the theoryx5 packages have resolved the Apache problems, as the lack of
a database connection limits what I can test. However, it does appear
that this may have resolved that issue. However, this build of DBD-Pg
appears to have other problems that prevent it working at all (and
appears that these may be known issues with this version of DBD-Pg).

As an alternative I've tried using ODBC to get to the database. The ODBC
package works fine standalone, but also exhibits the msvcrt problems
running under Apache. This is another package that I don't know the
build history of, and there is no known consistent package available at
theoryx5.

I've just tried a 2.14 DBD-Pg package from trouchelle.com, but have no
details of how this was constructed,, and this takes over and installs a
heap of replacement dll's. This won't even start standalone, and I'm
probably going to have to do a clean Perl install to recover from that.

Still struggling

Andrew




------=_NextPart_000_0000_01CB4D07.A09DD840
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



charset=3Dus-ascii">

RE: [DBI] msvcrt.dll issues when running in an XP environment

On zo, 2010-09-05 at 14:35 +1200, Andrew McLaren wrote:
> Still struggling

Hi Andrew,

You might want to check out StrawberryPerl @ http://strawberryperl.com/
- They provide lots of often used binary modules, such as DBD::Pg,
pre-installed, and they go through a great deal of trouble to make sure
the dll's won't clash with any other DLLs that happen to be inside your
path. This might just help you.

There are also packages available for using mod_perl with Strawberry:
http://strawberryperl.com/package/kmx/mod_perl/

You should no longer need to hunt for PPD packages (actually, you'd
better not) but you can install everything with the bundled CPAN client
and build environment.

Hope it helps,

Mike.

RE: [DBI] msvcrt.dll issues when running in an XP environment

Thanks for the support and ideas. I eventually came to the conclusion
that even if I got this resolved, it was likely to be an ongoing
management issue, so have decided to go the Linux route. This is now all
running on Apache/mod_perl there with minimal problems. Now alls that
left on Windows is a linked Access database to give me a quick and dirty
query interface into the DB.

Regards

Andrew

Re: [DBI] msvcrt.dll issues when running in an XP environment

Andrew McLaren schrieb am 12.09.2010 um 22:52 (+1200):
>
> Thanks for the support and ideas. I eventually came to the conclusion
> that even if I got this resolved, it was likely to be an ongoing
> management issue, so have decided to go the Linux route. This is now
> all running on Apache/mod_perl there with minimal problems. Now alls
> that left on Windows is a linked Access database to give me a quick
> and dirty query interface into the DB.

Good you've been able to nicely solve the issue.

From running some basic experiments, I'd think that on Windows,
IIS/ActivePerl/PerlEx would be a good solution. But there is
little user feedback available on the net, which lends a somewhat,
well, experimental or pioneering touch to the whole undertaking.

Anyone around here ever tried that combo? Or has feedback on it?
--
Michael Ludwig