Segfault when connecting during Apache startup with Apache::DBI - modperl

This is a discussion on Segfault when connecting during Apache startup with Apache::DBI - modperl ; 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: BI does not ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 29

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

  1. 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:BI 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:BI 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:BI

    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...done.
    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...done.
    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


  2. 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:BI


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

    --Tobias


  3. 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:BI
    >
    > I should have mentioned that we're using DBI 1.605, Apache:BI 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


  4. 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


  5. 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:BI. 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:BI 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


  6. 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:BI. 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:BI 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



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


  8. 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:BI 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


  9. 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:BI 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


  10. Re: Lost connection to MySQL server during query (was "Segfault when connecting during Apache startup")

    Quoting Perrin Harkins :
    > On Mon, Jun 30, 2008 at 4:54 AM, Tobias Kremer wrote:
    > > We never fork and I thought that Apache:BI 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:BI 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:BI;
    {
    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:atabase::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


  11. Re: Lost connection to MySQL server during query (was "Segfault when connecting during Apache startup")

    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


  12. 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


  13. Re: Lost connection to MySQL server during query (was "Segfault when connecting during Apache startup")

    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:BI;
    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


  14. Re: Lost connection to MySQL server during query (was "Segfault whenconnecting during Apache startup")

    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:BI can't help you if the connection goes away.

    --
    Michael Peters
    Plus Three, LP


  15. Re: Lost connection to MySQL server during query (was "Segfault when connecting during Apache startup")

    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:BI 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:BI
    should automatically avoid caching this connection.

    --Tobias


  16. Re: Lost connection to MySQL server during query (was "Segfault when connecting during Apache startup")

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


    It's not Apache:BI 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:BI 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


  17. Re: Lost connection to MySQL server during query (was "Segfault whenconnecting during Apache startup")

    Tobias Kremer wrote:
    > Quoting Michael Peters :
    >> Why are you storing the DB handle in a global variable?
    >> If you do that then Apache:BI 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:BI 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:BI'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:BI 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:BI
    > should automatically avoid caching this connection.


    Apache:BI doesn't store the cached handle, but your application does. That's
    the problem. Apache:BI 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


  18. Re: Lost connection to MySQL server during query (was "Segfault when connecting during Apache startup")

    On 30.06.2008, at 17:10, Perrin Harkins wrote:
    > It's not Apache:BI 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:BI 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:ServerConfig...se_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


  19. Re: Lost connection to MySQL server during query (was "Segfault when connecting during Apache startup")

    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:BI 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


  20. Re: Lost connection to MySQL server during query (was "Segfault when connecting during Apache startup")

    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:BI 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:BI 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:BI correctly reports
    that it won't cache it. Maybe now's the time to file a bug report ...

    --Tobias


+ Reply to Thread
Page 1 of 2 1 2 LastLast