I solved the prob I had some time ago (see below) by adding "PerlModule
BerkeleyDB" to the httpd.conf:
...
# Load Apache::Registry
PerlModule Apache::Registry
# Load Berkeley DB
PerlModule BerkeleyDB
...
It runs fine now.
But I'm not exactly sure what went wrong in the old situation. The
environment var $Env is a global var that should be persistent across
calls (and it is), but apparently something within BerkeleyDB is not.
Anyone?
Rick
Rick said on 15/4/05 11:09:
> I'm converting an existing CGI-script that uses Berkely DB with CDB to a
> mod_perl version, and I'm running into a problem. The first run works
> fine, but the second hit causes a "child pid ... exit signal
> Segmentation fault (11)" in the following line, UNLESS I close the
> environment after each run, and re-open it for the next run. Alas, this
> causes overhead that I'd rather get rid of:
>
> sub Something {
>
> # crashes:
> my $DB_Object = new BerkeleyDB::Hash
> -Filename => $DB,
> -Env => $Env,
> -Flags => DB_RDONLY ...
> }
>
> To avoid name collisions the application is split in a main program
> calling a run-routine from a separate module, as follows:
>
> use strict;
> use Appl::ApplMain;
>
> Appl::ApplMain::run();
>
>
> This is the separate module Appl/ApplMain.pm:
>
> package Appl::ApplMain;
>
> my $Env = new BerkeleyDB::Env ....
>
> sub run {
> <open env if not open>
> <processing>
> <*close env*>
> }
>
> 1;
>
> If I leave out the <close env> the child gets killed on the second run,
> if I close the environment it runs fine.
>
> Interestingly, if I don't put the run-subroutine in a separate module,
> but in a *library* that is require-d in the main program, it runs fine,
> but this has other implications for name space collisions.
>
> What obvious thing am I missing? Thanks for ideas!
>
> (Apache 1.33, Perl 5.8.6, mod_perl 1.29, BerkeleyDB 4.2.52, Perl
> interface 0.25)
>
