staunch has asked for the wisdom of the Perl Monks concerning the following question:

Hello, I'm having a difficult time using Apache::Session::Postgres and DBI together.
I can use DBI and Apache::Session::Postgres at the same time if they open separate database connections.
But, Apache(mod_perl) segfaults if I pass the database handle to Apache::Session::Postgres.

Configuration and versions:
Apache 1.3.20
mod_perl 1.26
PostgreSQL 7.1
Apache::Session 1.54
Apache::Session::Postgres 1.01
DBI 1.201

This causes a segmentation fault:

my($dbh) = DBI->connect('dbi:Pg:dbname=dbhere', 'userhere', 'passhere' +, { AutoCommit => 1, RaiseError => 1, }) || die("DBI->connect() failed: $DBI::errstr"); tie(%session, 'Apache::Session::Postgres', undef(), { Handle => $dbh, Commit => 1, });
They work fine separately like this:
my($dbh) = DBI->connect('dbi:Pg:dbname=dbhere', 'userhere', 'passhere' +, { AutoCommit => 1, RaiseError => 1, }) || die("DBI->connect() failed: $DBI::errstr"); tie(%session, 'Apache::Session::Postgres', undef(), { DataSource => 'dbi:Pg:dbname=dbhere', UserName => 'userhere', Password => 'passhere', Commit => 1, });
Here is the second error I get, which I assume happens because of the previous segfault problem:
DBD::Pg::st execute failed: pqReadData() -- read() failed: errno=88 a +t /usr/lib/perl5/site_perl/Apache/Session/Store/ line 65. (in cleanup) DBD::Pg::st execute failed: pqReadData() -- read() faile +d: errno=88 at /usr/lib/perl5/site_perl/Apache/Session/Store/ l +ine 65.
I know I'm enabling autocommit multiple times, but I've tried every combination of (Auto)Commit, so I don't think that's the problem.
My random guess is that there is some variable or handle sharing problem, something isn't being released, (un)locked, committed, disconnected or whatever :)
But I really have no idea, that's why I'm asking the learned monks of Perl.

I've google'd, checked the mod_perl guide, and a few other places.
If I missed something, an RTFM with a little info about what manual to read would be welcome.
If I left any necessary information out, please let me know.

Thanks in advance,

Replies are listed 'Best First'.
Re: Trouble with mod_perl, Apache::Session::Postgres, and DBI
by wmono (Friar) on Feb 03, 2002 at 22:04 UTC

    I'll start off by admitting that I typically use MySQL, and that I'm only starting to get into mod_perl and CGI in Perl. That said, I had a segfault problem just yesterday with a non-obvious solution. This is a story. I have no idea if this will help you, but I'll tell it because it just might.

    My system is Debian GNU/Linux of no particular version, having been upgraded in bits and pieces since it was installed eons ago. (Package names I mention here will be the Debian packages.) The script in question worked fine from the command line, but causeed an irritatingly uninstructive "[notice] child pid 32570 exit signal Segmentation fault (11)" to appear in Apache's error log when run under mod_perl. Other scripts ran just fine under mod_perl, and even the very one causing trouble ran fine if I removed the DBI->connect() call.

    I started my journey at uh... segfault. mod_perl, Apache::DBI and other atrocities., which suggests compiling Apache with --disable-rule=EXPAT. Unfortunately, that didn't seem to help me at all. I think this one's worth looking at anyway, though, as it seems to be a common problem. It's common enough that it's documented in the Apache sources.

    Following this lead, I started recompiling everything that could be possibly related to this problem. It sure looked like some kind of library mismatch problem. I recompiled mod_perl, I recompiled libmysqlclient10, I recompiled Apache a few more times, and so on. I stopped at recompiling libc6 because that was a bit of a serious undertaking, but I didn't think that would help anyway.

    Next, I scoured the web a bit more, using Google. I turned up mod_perl guide: Debugging mod_perl, which showed me a few more things to try.

    I ran apache with the -X option, so I could observe what it was doing. I ran tail -f on the Apache logs. The server started up, I connected and requested the troublesome page, and then the server segfaulted. Okay, that was not helpful. Then I ran it under strace to see what it was doing. Unfortunately, it made 160k of output, and nothing was obviously wrong near the end. That wasn't of much help.

    I fired up apache under gdb, as suggested by the guide. The last call was to db_open in Well, that didn't tell me anything really interesting, I thought, because my script was only segfaulting when I called DBI->connect().

    I did another web search, though, and discovered that installing libdb3 causes libdb2 programs to break on my type of system, in particular causing things like libns-db (which allows /etc/passwd and /etc/shadow to be databases) to break. Now, my system doesn't use database passwd or shadow, but I thought perhaps the libdb2/3 problem was affecting Apache and friends. First, I tried uninstalling libdb3, but that didn't work because libapache-mod-ssl depended on it. Hrmm, interesting. I tried upgrading both libdb3 and libapache-mod-ssl, but they were both the newest version. Even more interesting. Obviously libdb2 was the newest version, being one of the first things I tried upgrading. Well, let's just see what happens if I upgrade libns-db. .... oh, it's installing. Hm.

    Run apache.
    No segfault.
    Do the dance.

    That was a completely, totally, absolutely, unexpected solution.

    So, now we return to this problem. Have you tried running the script from the command line? How about under Apache, without mod_perl? Have you strace/truss'd apache -X, and did it tell you anything interesting? Did you try gdb (or your favourite debugger) on apache -X to see what it was doing right at the end? Some of these just might give you the clue you need to solve this one.

    Good luck!

      I haven't fixed the problem yet. But I did appreciate your story. It gave me a few more ideas of things to try. I'm still hoping not to go on any more of a recompiling rampage than I already have. It tends to be a whack-a-mole type game.

      I did try strace/truss/gdb, but nothing struck me as obvious.

      I tried running from the command line and CGI very early in trying to solve this and forgot about the output. Which may be more useful because it probably means this isn't strictly a mod_perl issue.

      Here is the error I get using CGI (non mod_perl):

      DBD::Pg::st execute failed: PQsendQuery() -- There is no connection to + the backend. at /usr/lib/perl5/site_perl/Apache/Session/Store/ + line 65.
      I think that if I can get this working under vanilla CGI, then mod_perl will work aswell.

      Thanks for the help,

Re: Trouble with mod_perl, Apache::Session::Postgres, and DBI
by trs80 (Priest) on Feb 03, 2002 at 22:04 UTC
    Did you create your session table? This was a thing that got me when I first used Apache::Session.
    You can see those docs with perldoc Apache::Session::Store::Postgres
    I would also recommend adding an additional timestamp field to the table for future session deletion based on time, it has come in handy for me.
      I created the session table the same as the docs specify. And I am using a timestamp field (for expiration).
      I didn't mention those things in my post in an attempt not to distract from the problem.
      If I open separate connections for DBI and Apache::Session::Postgres I can use them both just fine.

      Thanks though.

Re: Trouble with mod_perl, Apache::Session::Postgres, and DBI
by staunch (Pilgrim) on Feb 05, 2002 at 02:36 UTC
    I figured out what was causing the problem today. I was keeping a reference to %session around, for use in other parts of my program, then untie()ing it before I disconnect()'ed my database handle. Now I changed it so I untie() %session as soon as possible.
    This fixed the errors.

    Thanks for the help everyone.

Re: Trouble with mod_perl, Apache::Session::Postgres, and DBI
by perrin (Chancellor) on Feb 04, 2002 at 17:19 UTC
    Segfaults with mod_perl are often a result of using a mod_perl and perl libraries compiled with different versions of Perl. I'd suggest you compile Apache, mod_perl, and the DBI/PostgreSQL modules from source. It's a pain, but it will probably fix this.