Mailing List Archive: ModPerl: ModPerl

BerkelyDB problem - seg fault 11

Index | Next | Previous | View Threaded

jansmail at xs4all

Apr 15, 2005, 2:09 AM

Post #1 of 5 (538 views)
Permalink

BerkelyDB problem - seg fault 11

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)

--
Rick

perrin at elem

Apr 15, 2005, 8:19 AM

Post #2 of 5 (504 views)
Permalink

Re: BerkelyDB problem - seg fault 11 [In reply to]

Rick Jansen wrote:
> # crashes:
> my $DB_Object = new BerkeleyDB::Hash
> -Filename => $DB,
> -Env => $Env,
> -Flags => DB_RDONLY ...

The rest of the flags here may be relevant.

> To avoid name collisions the application is split in a main program
> calling a run-routine from a separate module

Does one of these run before mod_perl forks? That would cause problems.
Maybe the one above gets loaded at startup?

- Perrin

jansmail at xs4all

Apr 15, 2005, 2:46 PM

Post #3 of 5 (504 views)
Permalink

Re: BerkelyDB problem - seg fault 11 [In reply to]

Perrin Harkins zee op 15/4/05 17:19:

> Rick Jansen wrote:
>> # crashes:
>> my $DB_Object = new BerkeleyDB::Hash
>> -Filename => $DB,
>> -Env => $Env,
>> -Flags => DB_RDONLY ...
>
> The rest of the flags here may be relevant.
>
>> To avoid name collisions the application is split in a main program
>> calling a run-routine from a separate module
>
> Does one of these run before mod_perl forks? That would cause problems.
> Maybe the one above gets loaded at startup?

No, that should not be the case, I think. The env-open and the "new
BerkeleyDB::Hash" are actually called in the run routine, like below,
simplified. Any idea why it does run as a required library, but not as a
module?

Application:

use strict;
use Appl::ApplMain;

Appl::ApplMain::run();

Appl/ApplMain.pm:

package Appl::ApplMain;

my $Env;

sub run {
# Open env if not open
$Env = new BerkeleyDB::Env if (! $Env);

# crashes on second run if the close below is not done:
my $DB_Object = new BerkeleyDB::Hash
-Filename => $DB,
-Env => $Env,
-Flags => DB_RDONLY ...

$Env->close(); undef $Env; # Else crash on 2nd run...
} # run

1;

--
Rick

perrin at elem

Apr 15, 2005, 3:06 PM

Post #4 of 5 (499 views)
Permalink

Re: BerkelyDB problem - seg fault 11 [In reply to]

On Fri, 2005-04-15 at 23:46 +0200, Rick Jansen wrote:
> No, that should not be the case, I think. The env-open and the "new
> BerkeleyDB::Hash" are actually called in the run routine, like below,
> simplified.

What you have below will call run() during startup. All the code
outside of subs in your Application module is going to get run the first
time you use() the module.

> Application:
>
> use strict;
> use Appl::ApplMain;
>
> Appl::ApplMain::run();
>
>
> Appl/ApplMain.pm:
>
> package Appl::ApplMain;
>
> my $Env;
>
> sub run {
> # Open env if not open
> $Env = new BerkeleyDB::Env if (! $Env);
>
> # crashes on second run if the close below is not done:
> my $DB_Object = new BerkeleyDB::Hash
> -Filename => $DB,
> -Env => $Env,
> -Flags => DB_RDONLY ...
>
> $Env->close(); undef $Env; # Else crash on 2nd run...
> } # run

- Perrin

jansmail at xs4all

Jul 21, 2005, 1:32 AM

Post #5 of 5 (491 views)
Permalink

Re: BerkelyDB problem - seg fault 11 [In reply to]

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)
>

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads