Hi,

In order to make use of the ChildExitHandler introduced
in Apache::DBI 1.09, we upgraded Apache::DBI from 1.06 to 1.10.
But we immediately encounter seg faults errors for every request.
The problem is traced back to the line 160 of Apache::DBI 1.10:

# We may not actually be in a request, but in <Perl> (or
# equivalent such as startup.pl), in which case this would die.
eval { $r = Apache2::RequestUtil->request };

In Apache::DBI 1.06 $r is not used but $s is used. And no such
seg faults occur. Any one know what is the rational for this change?
Why is $r preferable to $s? It seems that $s is much more reliable.

Also, there is no testing on eval status by checking $ [at] right
after eval. As a module used by many, Apache::DBI should have checked
such status. Once I introduce such a test, I see errors like

Global $r object is not available. Set:
PerlOptions +GlobalRequest
in httpd.conf at /u01/perlgem_www/server/site_perl_debug/Apache/DBI.pm
line 160.

But adding

PerlOptions +GlobalRequest

in httpd.conf does not stop the seg faults from happening.

Does anyone else counter similar issues and knows a work around?

This is for

Apache/2.2.13 (Unix) mod_apreq2-20090110/2.7.1 mod_perl/2.0.4 Perl/v5.8.8

Thanks for any info.

Regards

Richard

There was this recent thread which may be helpful - I didn't follow it
that closely:

http://www.gossamer-threads.com/lists/modperl/modperl/102636


On Wed, Mar 2, 2011 at 8:10 AM, Richard Chen <richard [at] doubleprime.com> wrot=
e:
> Hi,
>
> =A0 =A0 =A0 =A0In order to make use of the ChildExitHandler introduced
> in Apache::DBI 1.09, we upgraded Apache::DBI from 1.06 to 1.10.
> But we immediately encounter seg faults errors for every request.
> The problem is traced back to the line 160 of Apache::DBI 1.10:
>
> =A0 =A0 =A0 =A0 =A0 =A0# We may not actually be in a request, but in <Per=
l> (or
> =A0 =A0 =A0 =A0 =A0 =A0# equivalent such as startup.pl), in which case th=
is would die.
> =A0 =A0 =A0 =A0 =A0 =A0eval { $r =3D Apache2::RequestUtil->request };
>
> =A0 =A0 =A0 =A0In Apache::DBI 1.06 $r is not used but $s is used. And no =
such
> seg faults occur. Any one know what is the rational for this change?
> Why is $r preferable to $s? It seems that $s is much more reliable.
>
> =A0 =A0 =A0 =A0Also, there is no testing on eval status by checking $ [at] ri=
ght
> after eval. As a module used by many, Apache::DBI should have checked
> such status. Once I introduce such a test, I see errors like
>
> Global $r object is not available. Set:
> =A0 =A0 =A0 =A0PerlOptions +GlobalRequest
> in httpd.conf at /u01/perlgem_www/server/site_perl_debug/Apache/DBI.pm
> line 160.
>
> But adding
>
> =A0 =A0 =A0 =A0PerlOptions +GlobalRequest
>
> in httpd.conf does not stop the seg faults from happening.
>
> Does anyone else counter similar issues and knows a work around?
>
> This is for
>
> Apache/2.2.13 (Unix) mod_apreq2-20090110/2.7.1 mod_perl/2.0.4 Perl/v5.8.8
>
> Thanks for any info.
>
> Regards
>
> Richard
>

Hi Richard,

> =A0 =A0 =A0 =A0In Apache::DBI 1.06 $r is not used but $s is used. And no =
such
> seg faults occur. Any one know what is the rational for this change?

Yes. It didn't work in Apache::DBI 1.06. Attaching a cleanup handler
to $s does not run that handler at the end of the current request,
which is what needs to happen here.

> Why is $r preferable to $s? It seems that $s is much more reliable.

They are totally different things. $s is the server, so the cleanup
would not get run until server shutdown.

> =A0 =A0 =A0 =A0Also, there is no testing on eval status by checking $ [at] ri=
ght
> after eval. As a module used by many, Apache::DBI should have checked
> such status.

I agree. The eval is intended to suppress the error you're seeing
though, since it happens when this code is called during startup but
isn't important.

So, the problem here is that your mod_perl is segfaulting when this is
called. That should not happen, and doesn't seem to be happening for
others. Can you try a simple test where you just try to grab a $r
inside an eval in your startup.pl and see if it segfaults?

- Perrin