Segfault when connecting during Apache startup with Apache::DBI

We have a mod_perl application that needs to connect to the database during
Apache startup to prefetch some data. The database handle for this is not
stored or re-used in any way.

According to the documentation, Apache::DBI does not cache database connections
made during server startup, so I should be fine. Unfortunately as soon as I
uncomment the lines in my ApacheHandler that connect to the database during
startup the Apache children throw segmentation faults on subsequent requests.

AFAIK the connection made during startup is not supposed to clash with the
connections made on a per-child basis during the handler() method via
DBI->connect() because it never gets cached anyway. But it seems that exactly
that is happening (Apache::DBI correctly warns me with "skipping connection
during server startup, read the docu").

The system looks like this:

- Ubuntu Feisty with apache-perl.
- stock Ubuntu Perl 5.8.8 (which unfortunately comes with threads)
- self-rolled DBD::mysql (against libmysqlclient15-dev), DBI and Apache::DBI

Here's the gdb output for the coredump:

This GDB was configured as "i486-linux-gnu"...
(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".

warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/tls/i686/cmov/libm.so.6...(no debugging symbols
found)...done.
Loaded symbols for /lib/tls/i686/cmov/libm.so.6
Reading symbols from /lib/tls/i686/cmov/libpthread.so.0...(no debugging symbols
found)...done.
Loaded symbols for /lib/tls/i686/cmov/libpthread.so.0
Reading symbols from /lib/tls/i686/cmov/libcrypt.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib/tls/i686/cmov/libcrypt.so.1
Reading symbols from /usr/lib/libdb-4.4.so...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libdb-4.4.so
Reading symbols from /usr/lib/libperl.so.5.8...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libperl.so.5.8
Reading symbols from /lib/tls/i686/cmov/libdl.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/tls/i686/cmov/libdl.so.2
Reading symbols from /lib/tls/i686/cmov/libc.so.6...(no debugging symbols
found)...done.
Loaded symbols for /lib/tls/i686/cmov/libc.so.6
Reading symbols from /usr/lib/libexpat.so.1...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libexpat.so.1
Reading symbols from /lib/ld-linux.so.2...
(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /usr/local/lib/perl/5.8.8/auto/Cwd/Cwd.so...done.
Loaded symbols for /usr/local/lib/perl/5.8.8/auto/Cwd/Cwd.so
Reading symbols from /usr/local/lib/perl/5.8.8/auto/List/Util/Util.so...done.
Loaded symbols for /usr/local/lib/perl/5.8.8/auto/List/Util/Util.so
Reading symbols from /usr/lib/perl/5.8.8/auto/Fcntl/Fcntl.so...done.
Loaded symbols for /usr/lib/perl/5.8/auto/Fcntl/Fcntl.so
Reading symbols from /usr/lib/perl/5.8.8/auto/IO/IO.so...done.
Loaded symbols for /usr/lib/perl/5.8/auto/IO/IO.so
Reading symbols from /usr/lib/perl5/auto/HTML/Parser/Parser.so...done.
Loaded symbols for /usr/lib/perl5/auto/HTML/Parser/Parser.so
Reading symbols from /usr/lib/perl/5.8.8/auto/File/Glob/Glob.so...done.
Loaded symbols for /usr/lib/perl/5.8/auto/File/Glob/Glob.so
Reading symbols from /usr/lib/perl/5.8.8/auto/Data/Dumper/Dumper.so...done.
Loaded symbols for /usr/lib/perl/5.8/auto/Data/Dumper/Dumper.so
Reading symbols from /usr/lib/perl/5.8.8/auto/B/B.so...done.
Loaded symbols for /usr/lib/perl/5.8/auto/B/B.so
Reading symbols from
/usr/local/lib/perl/5.8.8/auto/Apache/Request/Request.so...d one.
Loaded symbols for /usr/local/lib/perl/5.8.8/auto/Apache/Request/Request.so
Reading symbols from /usr/lib/perl5/auto/Apache/Symbol/Symbol.so...done.
Loaded symbols for /usr/lib/perl5/auto/Apache/Symbol/Symbol.so
Reading symbols from /usr/local/lib/perl/5.8.8/auto/DBI/DBI.so...done.
Loaded symbols for /usr/local/lib/perl/5.8.8/auto/DBI/DBI.so
Reading symbols from /usr/lib/perl/5.8.8/auto/MIME/Base64/Base64.so...done.
Loaded symbols for /usr/lib/perl/5.8/auto/MIME/Base64/Base64.so
Reading symbols from /usr/local/lib/perl/5.8.8/auto/Digest/SHA/SHA.so...done.
Loaded symbols for /usr/local/lib/perl/5.8.8/auto/Digest/SHA/SHA.so
Reading symbols from
/usr/local/lib/perl/5.8.8/auto/Apache/Cookie/Cookie.so...don e.
Loaded symbols for /usr/local/lib/perl/5.8.8/auto/Apache/Cookie/Cookie.so
Reading symbols from /usr/lib/perl/5.8.8/auto/Sys/Hostname/Hostname.so...done.
Loaded symbols for /usr/lib/perl/5.8/auto/Sys/Hostname/Hostname.so
Reading symbols from /usr/lib/perl/5.8.8/auto/Socket/Socket.so...done.
Loaded symbols for /usr/lib/perl/5.8/auto/Socket/Socket.so
Reading symbols from /usr/local/lib/perl/5.8.8/auto/Date/Calc/Calc.so...done.
Loaded symbols for /usr/local/lib/perl/5.8.8/auto/Date/Calc/Calc.so
Reading symbols from /usr/local/lib/perl/5.8.8/auto/Digest/SHA1/SHA1.so...done.
Loaded symbols for /usr/local/lib/perl/5.8.8/auto/Digest/SHA1/SHA1.so
Reading symbols from /usr/lib/perl/5.8.8/auto/Storable/Storable.so...done.
Loaded symbols for /usr/lib/perl/5.8/auto/Storable/Storable.so
Reading symbols from /usr/lib/perl/5.8.8/auto/Digest/MD5/MD5.so...done.
Loaded symbols for /usr/lib/perl/5.8/auto/Digest/MD5/MD5.so
Reading symbols from /usr/local/lib/perl/5.8.8/auto/DBD/mysql/mysql.so...done.
Loaded symbols for /usr/local/lib/perl/5.8.8/auto/DBD/mysql/mysql.so
Reading symbols from /usr/lib/libmysqlclient.so.15...done.
Loaded symbols for /usr/lib/libmysqlclient.so.15
Reading symbols from /lib/tls/i686/cmov/libnsl.so.1...done.
Loaded symbols for /lib/tls/i686/cmov/libnsl.so.1
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/tls/i686/cmov/libnss_files.so.2...done.
Loaded symbols for /lib/tls/i686/cmov/libnss_files.so.2
Reading symbols from /lib/libnss_mdns4_minimal.so.2...done.
Loaded symbols for /lib/libnss_mdns4_minimal.so.2
Reading symbols from /lib/tls/i686/cmov/libnss_dns.so.2...done.
Loaded symbols for /lib/tls/i686/cmov/libnss_dns.so.2
Reading symbols from /lib/tls/i686/cmov/libresolv.so.2...done.
Loaded symbols for /lib/tls/i686/cmov/libresolv.so.2
Reading symbols from /usr/lib/apache/1.3/mod_log_config.so...done.
Loaded symbols for /usr/lib/apache/1.3/mod_log_config.so
Reading symbols from /usr/lib/apache/1.3/mod_mime_magic.so...done.
Loaded symbols for /usr/lib/apache/1.3/mod_mime_magic.so
Reading symbols from /usr/lib/apache/1.3/mod_mime.so...done.
Loaded symbols for /usr/lib/apache/1.3/mod_mime.so
Reading symbols from /usr/lib/apache/1.3/mod_dir.so...done.
Loaded symbols for /usr/lib/apache/1.3/mod_dir.so
Reading symbols from /usr/lib/apache/1.3/mod_alias.so...done.
Loaded symbols for /usr/lib/apache/1.3/mod_alias.so
Reading symbols from /usr/lib/apache/1.3/mod_rewrite.so...done.
Loaded symbols for /usr/lib/apache/1.3/mod_rewrite.so
Reading symbols from /usr/lib/apache/1.3/mod_access.so...done.
Loaded symbols for /usr/lib/apache/1.3/mod_access.so
Reading symbols from /usr/lib/apache/1.3/mod_setenvif.so...done.
Loaded symbols for /usr/lib/apache/1.3/mod_setenvif.so
Reading symbols from /lib/tls/i686/cmov/libnss_compat.so.2...done.
Loaded symbols for /lib/tls/i686/cmov/libnss_compat.so.2
Reading symbols from /lib/tls/i686/cmov/libnss_nis.so.2...done.
Loaded symbols for /lib/tls/i686/cmov/libnss_nis.so.2
Core was generated by `/usr/sbin/apache-perl'.
Program terminated with signal 11, Segmentation fault.
#0 0xb775a89b in mysql_ping () from /usr/lib/libmysqlclient.so.15

So it fails during the call to mysql_ping() but I can't see why this is
happening.

Any ideas?

Thanks!

--Tobias

Re: Segfault when connecting during Apache startup with Apache::DBI

> - Ubuntu Feisty with apache-perl.
> - stock Ubuntu Perl 5.8.8 (which unfortunately comes with threads)
> - self-rolled DBD::mysql (against libmysqlclient15-dev), DBI and Apache::DBI

I should have mentioned that we're using DBI 1.605, Apache::DBI 1.07 and
DBD::mysql 4.007. The Ubuntu apache-perl package consists of Apache 1.3.34 and
mod_perl/1.29.

--Tobias

Re: Segfault when connecting during Apache startup with Apache::DBI

Quoting Tobias Kremer :

> > - Ubuntu Feisty with apache-perl.
> > - stock Ubuntu Perl 5.8.8 (which unfortunately comes with threads)
> > - self-rolled DBD::mysql (against libmysqlclient15-dev), DBI and
> Apache::DBI
>
> I should have mentioned that we're using DBI 1.605, Apache::DBI 1.07 and
> DBD::mysql 4.007. The Ubuntu apache-perl package consists of Apache 1.3.34
> and
> mod_perl/1.29.

After de-installing the latest (self-rolled) DBI and DBD::mysql modules and
installing the corresponding packages provided by Ubuntu (libdbd-mysql-perl and
libdbi-perl) the segfaults are gone. Anyone know what could have gone wrong
during make'ing my own DBI/DBD::mysql? I'd really like to use the most current
versions of those two modules instead of the outdated Ubuntu ones (DBI 1.53,
DBD::mysql 3.0008).

--Tobias

Re: Segfault when connecting during Apache startup with Apache::DBI

Quoting André Warnier :
> I don't know if the above versions are imposed to you, but in case you
> have a choice, I would recommend de-installing your Apache and mod_perl,
> and re-install the Apache 2.2 version and the mod_perl that goes with it.
> Apache 1.x and mod_perl 1.x are old versions, and you will have trouble
> finding someone able to help you.

Unfortunately, switching to Apache2/mod_perl2 is not an option at this time :(
Besides, I doubt that everyone here already erased their entire mod_perl 1
knowledge. Where are my old-hands? ;-)

--Tobias

Re: Segfault when connecting during Apache startup with Apache::DBI

On Wed, Jun 25, 2008 at 5:49 AM, Tobias Kremer wrote:
> After de-installing the latest (self-rolled) DBI and DBD::mysql modules and
> installing the corresponding packages provided by Ubuntu (libdbd-mysql-perl and
> libdbi-perl) the segfaults are gone.

It sound like this is a problem with the new DBD::mysql then, rather
than Apache::DBI. If you want to determine that the problem is the
version and not your compile options, you can compile the Ubuntu
versions yourself and see if they segfault.

Another possibility here is that although Apache::DBI doesn't cache
the connections, your code does. If you put them in globals or
closures during startup and try to use them later, I would expect
segfaults.

- Perrin

Re: Segfault when connecting during Apache startup with Apache::DBI

I had big trouble with DBD::mysql 4.007. I didn't get rid of my
segfault problem running mod_perl 1.31 until I went back to 4.004.


Amiri


On Jun 25, 2008, at 12:14 PM, Perrin Harkins wrote:

> On Wed, Jun 25, 2008 at 5:49 AM, Tobias Kremer
> wrote:
>> After de-installing the latest (self-rolled) DBI and DBD::mysql
>> modules and
>> installing the corresponding packages provided by Ubuntu (libdbd-
>> mysql-perl and
>> libdbi-perl) the segfaults are gone.
>
> It sound like this is a problem with the new DBD::mysql then, rather
> than Apache::DBI. If you want to determine that the problem is the
> version and not your compile options, you can compile the Ubuntu
> versions yourself and see if they segfault.
>
> Another possibility here is that although Apache::DBI doesn't cache
> the connections, your code does. If you put them in globals or
> closures during startup and try to use them later, I would expect
> segfaults.
>
> - Perrin

Re: Segfault when connecting during Apache startup with Apache::DBI

On 25.06.2008, at 20:58, Amiri Barksdale wrote:
> I had big trouble with DBD::mysql 4.007. I didn't get rid of my
> segfault problem running mod_perl 1.31 until I went back to 4.004.

Thanx. It really looks a lot like my problem:

http://bugs.mysql.com/bug.php?id=36810

I'll try reverting to an earlier version of DBD::mysql.

--Tobias

Re: Segfault when connecting during Apache startup with Apache::DBI

Quoting Tobias Kremer :

> On 25.06.2008, at 20:58, Amiri Barksdale wrote:
> > I had big trouble with DBD::mysql 4.007. I didn't get rid of my
> > segfault problem running mod_perl 1.31 until I went back to 4.004.
>
> Thanx. It really looks a lot like my problem:
>
> http://bugs.mysql.com/bug.php?id=36810
>
> I'll try reverting to an earlier version of DBD::mysql.

The latest DBD::mysql really seems to be the culprit. Even on a freshly
installed Ubuntu 8.04 with the stock Perl 5.8.8 but self-compiled MySQL
5.0.51a, Apache 1.3.41, mod_perl 1.30, DBI 1.605 and DBD 4.0007 I'm getting
segmentation faults. After installing DBD 4.0004 everything works fine. Of
course, I made sure that the correct MySQL library was linked.

I can't understand what 4.0007 is still doing on CPAN as the most recent
version. But maybe this still is an Ubuntu and/or MP1 related thing - even with
most components rolled by myself ...

Now if I could just get rid of those annoying random "Commands out of sync" and
"Lost connection to MySQL server during query" errors that happen once in a
while ...

--Tobias

RE: Segfault when connecting during Apache startup with Apache::DBI

On AIX 5.2 I am using Perl 5.8.0, MySQL 5.0.51a, Apache 2.2.28, mod_perl
2.04, DBI 1.604 and DBD 4.0007 and it all works good.

--Brian

-----Original Message-----
From: Tobias Kremer [mailto:list@funkreich.de]=20
Sent: Friday, June 27, 2008 5:51 AM
To: modperl@perl.apache.org
Subject: Re: Segfault when connecting during Apache startup with
Apache::DBI

Quoting Tobias Kremer :

> On 25.06.2008, at 20:58, Amiri Barksdale wrote:
> > I had big trouble with DBD::mysql 4.007. I didn't get rid of my=20
> > segfault problem running mod_perl 1.31 until I went back to 4.004.
>
> Thanx. It really looks a lot like my problem:
>
> http://bugs.mysql.com/bug.php?id=3D36810
>
> I'll try reverting to an earlier version of DBD::mysql.

The latest DBD::mysql really seems to be the culprit. Even on a freshly
installed Ubuntu 8.04 with the stock Perl 5.8.8 but self-compiled MySQL
5.0.51a, Apache 1.3.41, mod_perl 1.30, DBI 1.605 and DBD 4.0007 I'm
getting segmentation faults. After installing DBD 4.0004 everything
works fine. Of course, I made sure that the correct MySQL library was
linked.

I can't understand what 4.0007 is still doing on CPAN as the most recent
version. But maybe this still is an Ubuntu and/or MP1 related thing -
even with most components rolled by myself ...

Now if I could just get rid of those annoying random "Commands out of
sync" and "Lost connection to MySQL server during query" errors that
happen once in a while ...

--Tobias

Re: Segfault when connecting during Apache startup with Apache::DBI

On Fri, Jun 27, 2008 at 5:51 AM, Tobias Kremer wrote:
> Now if I could just get rid of those annoying random "Commands out of sync" and
> "Lost connection to MySQL server during query" errors that happen once in a
> while ...

Those generally mean that you timed out (set MySQL's timeouts longer)
or did something incorrectly with forking.

- Perrin

Re: Segfault when connecting during Apache startup with Apache::DBI

Quoting Perrin Harkins :
> On Fri, Jun 27, 2008 at 5:51 AM, Tobias Kremer wrote:
> > Now if I could just get rid of those annoying random "Commands out of sync"
> and
> > "Lost connection to MySQL server during query" errors that happen once in a
> > while ...
> Those generally mean that you timed out (set MySQL's timeouts longer)
> or did something incorrectly with forking.

We never fork and I thought that Apache::DBI takes care of checking if a
connection went stale by utilizing DBI's/DBD::mysql's ping() method? Sometimes
I'm also seeing this error seconds after restarting the mod_perl Apache - I
think that there should be only fresh connections then ...

Any other ideas? Thanks!

--Tobias

Re: Segfault when connecting during Apache startup with Apache::DBI

On Mon, Jun 30, 2008 at 4:54 AM, Tobias Kremer wrote:
> We never fork and I thought that Apache::DBI takes care of checking if a
> connection went stale by utilizing DBI's/DBD::mysql's ping() method?

It does, but it can't stop you from doing things like putting a
database handle in a global during startup and trying to use it later.

> Sometimes
> I'm also seeing this error seconds after restarting the mod_perl Apache - I
> think that there should be only fresh connections then ...

That's a different kind of timeout. I meant you may have a really
slow query that takes too long to read from MySQL, not that the
handles would be stale.

Getting errors right after startup makes it sound more likely that you
are storing the database handles you open during startup and trying to
use them.

- Perrin

Re: Lost connection to MySQL server during query (was "Segfault when connecting during Apache s

Quoting Perrin Harkins :
> On Mon, Jun 30, 2008 at 4:54 AM, Tobias Kremer wrote:
> > We never fork and I thought that Apache::DBI takes care of checking if a
> > connection went stale by utilizing DBI's/DBD::mysql's ping() method?
> It does, but it can't stop you from doing things like putting a
> database handle in a global during startup and trying to use it later.

Ok, I narrowed it down to the database connection initiated during server
startup. As soon as I remove it the errors vanish completely. But I don't
understand why this is causing a problem because Apache::DBI is supposed to not
cache connections made during server startup - it even correctly issues a
warning.

Here are some snippets to illustrate what I'm doing:

-----------------------------------
ApacheHandler.pm
-----------------------------------
use Apache::DBI;
{
package HTML::Mason::Commands;
use vars qw/ $thefoo /;
}
my $foo = My::Foo->new();
sub handler {
$HTML::Mason::Commands::thefoo = $foo;
}

-----------------------------------
My/Foo.pm
-----------------------------------
sub new {
my $dbh = My::Database::dbh();
my $result = $dbh->selectall_arrayref( ... );
# create an object of e.g. My::Bar initialized with row data
# and store it in $self. $dbh is never stored somewhere!
$dbh->disconnect();
}

-----------------------------------
My/Database.pm
-----------------------------------
use DBI;
sub dbh { DBI->connect( ... ) }


Any ideas? Thanks a lot!

--Tobias

Re: Lost connection to MySQL server during query (was "Segfault when connecting during Apache s

On Mon, Jun 30, 2008 at 9:28 AM, Tobias Kremer wrote:
> Ok, I narrowed it down to the database connection initiated during server
> startup. As soon as I remove it the errors vanish completely.

Good, that's major progress.

> Here are some snippets to illustrate what I'm doing:

I don't see anything in this code, but you're not really showing us
much here. I think you'll need to try commenting out parts of it
until you find which part breaks it. I'd start with that
selectall_arrayref that you store.

- Perrin

Re: Segfault when connecting during Apache startup with Apache::DBI

On Mon, Jun 30, 2008 at 10:54:20AM +0200, Tobias Kremer wrote:
> Any other ideas? Thanks!

It could be that your query(result) is too large for the
'max_allowed_packet' setting. The mysql-client that is connected to your
process will then silently die, giving the 'Lost mysql...' error as
result. Raising it on your server (in my.cnf or similar) can solve the
problem.

Kind regards,
Frank

Re: Lost connection to MySQL server during query (was "Segfault when connecting during Apache s

Quoting Perrin Harkins :
> I don't see anything in this code, but you're not really showing us
> much here. I think you'll need to try commenting out parts of it
> until you find which part breaks it. I'd start with that
> selectall_arrayref that you store.

I can reproduce the problem with the following minimal setup:

package LostHandler;
use Apache::DBI;
use DBI;
use LostDatabase;
use LostFoo;
use vars qw( $dbh $thefoo );
my $foo = LostFoo->new();
sub handler {
$thefoo = $foo;
$dbh = LostDatabase::dbh();
$dbh->do( "SELECT 1" );
return 200;
}
1;

-----------------------

package LostFoo;
use LostDatabase;
sub new {
my $self = {};
my $dbh = LostDatabase::dbh();
$dbh->do( "SELECT 2" );
$dbh->disconnect();
bless $self, shift;
}
1;

-----------------------

package LostDatabase;
sub dbh { DBI->connect('dbi:mysql:test','','') }
1;

Hammering this with "ab -n 1000 -c 30" gives me the "Lost connection" and/or
"DBD driver has not implemented the AutoCommit attribute" error after the first
couple of requests. Removing the lines:

my $foo = LostFoo->new();
$thefoo = $foo;

makes the error disappear completely.

I've had this problem on many systems and never really bothered because it only
shows up on our rather busy system after the server gets restarted but somehow
it gives me headaches to not know where it is coming from ...

--Tobias

Re: Lost connection to MySQL server during query (was "Segfault whenconnecting during Apache st

Tobias Kremer wrote:

> use vars qw( $dbh $thefoo );

Why are you storing the DB handle in a global variable?

If you do that then Apache::DBI can't help you if the connection goes away.

--
Michael Peters
Plus Three, LP

Re: Lost connection to MySQL server during query (was "Segfault when connecting during Apache s

Quoting Michael Peters :
> Tobias Kremer wrote:
> > use vars qw( $dbh $thefoo );
> Why are you storing the DB handle in a global variable?
> If you do that then Apache::DBI can't help you if the connection goes away.

To make this variable available to all Mason components. Theoretically, this
shouldn't be a problem because I'm (re-)connecting on every request in the
handler() subroutine not once during startup. Actually it works perfectly as
soon as you remove the one-time connection made during startup (LostFoo) which
just preloads some data from the database. According to the docs Apache::DBI
should automatically avoid caching this connection.

--Tobias

Re: Lost connection to MySQL server during query (was "Segfault when connecting during Apache s

On Mon, Jun 30, 2008 at 11:02 AM, Tobias Kremer wrote:
> According to the docs Apache::DBI
> should automatically avoid caching this connection.

It's not Apache::DBI that's caching it -- you're caching it. Don't
put a database handle in a global before you fork. It will stay, and
there's nothing Apache::DBI can do about it.

You are probably not reusing this connection, but you don't need to.
It will sit there, open, and eventually time out, which will cause the
error messages you see and also trigger cleanup on the server side.
The server side cleanup may hurt other open connections from the same
process.

So, never put a database handle in a global during startup.

- Perrin

Re: Lost connection to MySQL server during query (was "Segfault whenconnecting during Apache st

Tobias Kremer wrote:
> Quoting Michael Peters :
>> Why are you storing the DB handle in a global variable?
>> If you do that then Apache::DBI can't help you if the connection goes away.
>
> To make this variable available to all Mason components.

Then use a method to do this, not a global variable. Have that method call
DBI->connect every time you want to get the handle. If Apache::DBI has already
made the connection it will return a cached handle for you. No need to try
caching it on your own. It will only cause problems because it means you're not
using Apache::DBI's cache.

> Theoretically, this
> shouldn't be a problem because I'm (re-)connecting on every request in the
> handler() subroutine not once during startup.

You're trying to do too much work. Let Apache::DBI worry about connecting,
reconnecting, caching, etc.

> Actually it works perfectly as
> soon as you remove the one-time connection made during startup (LostFoo) which
> just preloads some data from the database.

Except for all those timeout errors you mention :)

> According to the docs Apache::DBI
> should automatically avoid caching this connection.

Apache::DBI doesn't store the cached handle, but your application does. That's
the problem. Apache::DBI can't get rid of that handle if you're storing it
someplace and then trying to use it later.

--
Michael Peters
Plus Three, LP

Re: Lost connection to MySQL server during query (was "Segfault when connecting during Apache s

On 30.06.2008, at 17:10, Perrin Harkins wrote:
> It's not Apache::DBI that's caching it -- you're caching it. Don't
> put a database handle in a global before you fork. It will stay, and
> there's nothing Apache::DBI can do about it.

Could you please show me the exact line in my example in which I put
the database handle in a
global during startup? To me it looks like I'm correctly _declaring_ a
global variable ($dbh) on
server startup, but the connect happens in the handler() subroutine.
There's even an example in
the Mason docs that recommends this approach:
http://masonhq.com/?FAQ:ServerConfiguration#h-how_do_i_conne ct_to_a_database_from_mason_

And this all works great - without _any_ errors at all! It's not until
I start adding my preloading
stuff which fetches some stuff from the database during startup with a
supposedly independent not-cached
handle which should have got nothing to do with my global $dbh that
the errors crop up.

Thank you very much! :)

--Tobias

Re: Lost connection to MySQL server during query (was "Segfault when connecting during Apache s

On Mon, Jun 30, 2008 at 1:40 PM, Tobias Kremer wrote:
> Could you please show me the exact line in my example in which I put the
> database handle in a
> global during startup?

On a closer look, you're not. You are keeping around your $foo
closure variable in handler(), as well as putting it in a global.
It's not obvious why that causes this problem. If you want to
determine whether Apache::DBI is malfunctioning for you in some way,
I'd suggest just removing it and seeing if the problem goes away.
Your test app should work fine without it.

> There's even an example in
> the Mason docs that recommends this approach

I know, but it's still a bad idea, IMO. The Mason docs advise a
similar approach for using sessions and people are constantly having
problems with their session object not getting cleaned up.

- Perrin

Re: Lost connection to MySQL server during query (was "Segfault when connecting during Apache s

Quoting Perrin Harkins :
> On a closer look, you're not. You are keeping around your $foo
> closure variable in handler(), as well as putting it in a global.
> It's not obvious why that causes this problem. If you want to
> determine whether Apache::DBI is malfunctioning for you in some way,
> I'd suggest just removing it and seeing if the problem goes away.
> Your test app should work fine without it.

Removing Apache::DBI makes the errors go away. Using two different connection
strings for my initial connection during startup and the subsequent connections
in the handler() method also works. So everything looks like the connection made
during startup is indeed re-used somehow, although Apache::DBI correctly reports
that it won't cache it. Maybe now's the time to file a bug report ...

--Tobias

Re: Lost connection to MySQL server during query (was "Segfault when connecting during Apache s

On Tue, Jul 1, 2008 at 3:42 AM, Tobias Kremer wrote:
> Removing Apache::DBI makes the errors go away.

Ok. First, check that you're on the latest version. Then, turn on
the debug flag and see if it thinks it is reusing the startup
connection or not.

- Perrin

Re: Lost connection to MySQL server during query (was "Segfault when connecting during Apache s

On Tue, Jul 1, 2008 at 9:56 AM, Tobias Kremer wrote:
> Yes, I'm using the latest 1.07 release. I already had the debug flag on and it's
> correctly telling me that it's "skipping connection during server startup".

Yes, but what does it tell you on the first connection AFTER startup?
It should say whether it's making a new connection or not.

- Perrin

Re: Lost connection to MySQL server during query (was "Segfault when connecting during Apache s

Quoting Perrin Harkins :
> Ok. First, check that you're on the latest version. Then, turn on
> the debug flag and see if it thinks it is reusing the startup
> connection or not.

Yes, I'm using the latest 1.07 release. I already had the debug flag on and it's
correctly telling me that it's "skipping connection during server startup".

--Tobias

Re: Lost connection to MySQL server during query (was "Segfault when connecting during Apache s

Quoting Perrin Harkins :
> Yes, but what does it tell you on the first connection AFTER startup?
> It should say whether it's making a new connection or not.

Here's the complete debug output which suggests that the connection during
startup is reused for the first request.

On server start:
----------------
20097 Apache::DBI skipping connection during server startup, read the docu !!
20097 Apache::DBI push PerlCleanupHandler
20097 Apache::DBI need ping: yes
20097 Apache::DBI new connect to 'foo:bar...'
20097 Apache::DBI disconnect (overloaded)

On first request:
----------------
20099 Apache::DBI need ping: yes
20099 Apache::DBI already connected to 'foo:bar...'
20099 Apache::DBI PerlCleanupHandler

--Tobias

Re: Lost connection to MySQL server during query (was "Segfault when connecting during Apache s

On Tue, Jul 1, 2008 at 10:08 AM, Tobias Kremer wrote:
> On server start:
> ----------------
> 20097 Apache::DBI skipping connection during server startup, read the docu !!
> 20097 Apache::DBI push PerlCleanupHandler
> 20097 Apache::DBI need ping: yes
> 20097 Apache::DBI new connect to 'foo:bar...'
> 20097 Apache::DBI disconnect (overloaded)

That looks like two different connect attempts. The line following
the "skipping" part is a return, and then it must come back in later.

How are you loading this? With a PerlModule call? Can you try
loading it from a Perl section like this?


use MyModule;


- Perrin

Re: Lost connection to MySQL server during query (was "Segfault when connecting during Apache s

Quoting Perrin Harkins :
> How are you loading this? With a PerlModule call? Can you try
> loading it from a Perl section like this?
>
> use MyModule;
>

Wow, it seems that this fixes the problem! At least with my minimal application.

Here's the debug output which looks quite promising IMHO:

On server start:
----------------
8816 Apache::DBI skipping connection during server startup, read the docu !!
[rest is gone!]

On first request:
-----------------
8818 Apache::DBI push PerlCleanupHandler
8818 Apache::DBI need ping: yes
8818 Apache::DBI new connect to 'foo:bar'
8818 Apache::DBI PerlCleanupHandler

This comes up a couple of times for every new process and afterwards
changes to "already connected" which is exactly the behaviour I expected in the
first place.

Do you have any idea what is going on? I'll check out how our real system
behaves with this change.

Thanks a lot, Perrin!

--Tobias

Re: Lost connection to MySQL server during query (was "Segfault when connecting during Apache s

Quoting Tobias Kremer :
> Quoting Perrin Harkins :
> > How are you loading this? With a PerlModule call? Can you try
> > loading it from a Perl section like this?
> >
> > use MyModule;
> >
> Wow, it seems that this fixes the problem!
> Do you have any idea what is going on? I'll check out how our real system
> behaves with this change.

No more errors there either! :)

I don't know anything about the internals but to me the mod_perl source looks
like PerlModule is using "require" instead of "use" to load modules. I guess
that is making the difference?

Whatever the cause is, I think it should be documented somewhere. I'd happily
provide a doc-patch for whatever documentation is suitable :)

--Tobias

Re: Lost connection to MySQL server during query (was "Segfault when connecting during Apache s

On Wed, Jul 2, 2008 at 5:12 AM, Tobias Kremer wrote:
> No more errors there either! :)

Great!

> I don't know anything about the internals but to me the mod_perl source looks
> like PerlModule is using "require" instead of "use" to load modules. I guess
> that is making the difference?

I don't know the details, but there is something about the way
PerlModule works in mod_perl 1 that causes it to load the module again
when apache restarts at startup (it runs yours conf file twice when
you start, as documented). Using an explicit use() puts an entry in
%INC and fixes the issue. This should happen with require() as well,
so I don't know what the problem is, but I've been told that mod_perl
2 doesn't have this problem.

There seems to be an additional bug in either Apache::DBI or mod_perl
1, since $Apache::ServerStarting == 1 seems not to be true the second
time through. Can you have your Perl section print out the values of
$Apache::ServerStarting and $Apache::ServerReStarting?

- Perrin

Re: Lost connection to MySQL server during query (was "Segfault when connecting during Apache s

> I don't know the details, but there is something about the way
> PerlModule works in mod_perl 1 that causes it to load the module again
> when apache restarts at startup (it runs yours conf file twice when
> you start, as documented). Using an explicit use() puts an entry in
> %INC and fixes the issue. This should happen with require() as well,
> so I don't know what the problem is, but I've been told that mod_perl
> 2 doesn't have this problem.

So, due to this being the mod_perl list there must be somebody here who knows
what's going on deep down in the guts of the beast :)

> There seems to be an additional bug in either Apache::DBI or mod_perl
> 1, since $Apache::ServerStarting == 1 seems not to be true the second
> time through. Can you have your Perl section print out the values of
> $Apache::ServerStarting and $Apache::ServerReStarting?

This gives me:

Apache::ServerStarting = 1
Apache::ServerReStarting = 0

once(!) on server startup - no matter if I "use" my handler or load it via
PerlModule.

--Tobias