Perl DBI program fails unexpectedly in Apache CGI-mode *only*

Perl DBI program fails unexpectedly in Apache CGI-mode *only*

Post by » Tue, 03 Mar 2009 14:16:44

Please refer to the thread, "Do XS-components require special
considerations with CGI?", found at
for a complete explanation of this problem.

I have a Perl CGI-program which works perfectly under Apache on my
development system, and in the command-line on the (ordinary Linux...)
shared host system, but which fails under Apache CGI-mode on that same

As I related at-length in the aforementioned thread on "perlmonks,"
with copious details that I therefore do not wish to repeat here... I
have captured logs produced by the program running in both
environments on the same machine with "DynaLoader" debug-messages
turned on in both cases. And, I have "diff"ed them.

(1) The =entire= log output of both, particularly including
"DynaLoader"'s recitation of the "@INC" path, is (almost) identical.
"DBD::mysql" and "DBI" are dynaloaded successfully.

(2) Here is the -only- difference ... the failure-indications that
appear only in the Apache CGI output:

[Sat Feb 28 19:41:12 2009] Had to create
DBD::mysql::dr::imp_data_size unexpectedly at .../local-perl/lib/perl/
5.8.8/ line 1212.
[Sat Feb 28 19:41:12 2009] Had to create
DBD::mysql::db::imp_data_size unexpectedly at .../local-perl/lib/perl/
5.8.8/ line 1242.
Demo FAILED with this error:
DBIx::Class::ResultSet::next(): DBI Connection failed:
Undefined subroutine &DBD::mysql::db::_login called at .../local-perl/
lib/perl/5.8.8/DBD/ line 142.

(In each of the above messages I have elided-out much of the path-name
just for brevity (".../local-perl"). I have verified that this IS, in
fact, exactly the right path to where "" is, and ought to be.

LD_LIBRARY_PATH in both cases (the working case and the non-working
case) is identical... it is "undef."

Remember: the program produces correct output in the command-line on
the selfsame system where it fails (gracefully...) when run in CGI-
mode. That is to say, the program runs, it generates its own "error
detected" output, loads all the right XS-modules, and so on.

Furthermore, a programmatic "ldd" command, issued by the program in
both environments for "" and '," produces
apparently-CORRECT output: there are no missing symbols.

After more than a week of banging my head against this problem, I am
utterly baffled ... and beyond desperate.