Bug 59742 - php-4.0.6-7 sometimes segfaults on certain postgresql queries
php-4.0.6-7 sometimes segfaults on certain postgresql queries
Product: Red Hat Linux
Classification: Retired
Component: php (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Phil Copeland
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2002-02-12 10:11 EST by Geoffrey D. Bennett
Modified: 2007-04-18 12:40 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-02-26 11:04:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
gdb backtraces after apache segfaults (4.00 KB, text/plain)
2002-02-12 10:12 EST, Geoffrey D. Bennett
no flags Details

  None (edit)
Description Geoffrey D. Bennett 2002-02-12 10:11:35 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20010901

Description of problem:
The following PHP program will sometimes cause Apache/PHP to segfault:

  $db = pg_connect("dbname=template1 user=postgres");
  pg_exec($db, "SELECT * FROM pg_tables WHERE pg_index.indproc = 1;");

It appears that the problem has to do with postgresql returning a
NOTICE (in this case "NOTICE:  Adding missing FROM-clause entry for table
"pg_index"), as I have not managed to get it to segfault with
a query that doesn't produce some message.

The segfault never seems to happen on the first PHP request that a particular
Apache child process handles, so a (very) crude workaround for this problem is
to set MaxRequestsPerChild to 1.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install apache, php, postgresql-server, php-pgsql, etc.
2. Start apache & postgresql.
3. Install the above PHP script.
4. Point your browser at the script.  Reload the page multiple times while
monitoring /var/log/httpd/error_log; the segfault may occur on the first reload,
or may take a few reloads.

Lowering the number of Apache handlers may help when trying to reproduce this
(with the default StartServer set to 8, it may take 15 reloads before you hit
the same server twice).

Actual Results:  Apache segfaults.

Expected Results:  Apache shouldn't segfault.

Additional info:

I will attach a couple of gdb backtraces which may be helpful, although the
segfault seems to happen in different places.
Comment 1 Geoffrey D. Bennett 2002-02-12 10:12:44 EST
Created attachment 45399 [details]
gdb backtraces after apache segfaults
Comment 2 Uriah Welcome 2002-02-19 19:59:46 EST
This is a known bug in php 4.0.6.  It causes random crashes when using the pgsql
module.  There is a section from the changelog of 4.1.0 here..

"* Fixed pg_last_notice() (could cause random crashes in PostgreSQL
applications, even if they didn't use pg_last_notice()). (Zeev)"
Comment 3 Need Real Name 2002-02-26 11:04:10 EST
Aha, this is it !
We are having problems with this all the time.
I hope RH will release a PHP update for RH 7.2 soon !

    Friendly greetings,
    Rob van Nieuwkerk

Sysinfo: well maintained RH 7.2 on Intel with all RH updates applied
Comment 4 Phil Copeland 2002-03-04 14:14:14 EST
Humm,... well it's not finished yet but you're welcome to try the php-4.1.2
rawhide package that I've been poking at. (It's a candiate for errata release)

Unfortunately it won't show up in rawhide until 03:00est Mar 5th due to the way
the build system here works
Give that a shot and get back to me if the postgres problem still persists

Comment 5 Need Real Name 2002-03-05 12:25:11 EST
Sure, we are willing to test your new php-4.1.2 (source) RPM.
But it's not there.  I even waited for some 10 extra hours
for it to show up.  There only a php-4.1.1-4.src.rpm which
is several weeks old ..

    Rob van Nieuwkerk
Comment 6 Phil Copeland 2002-03-05 13:30:52 EST
Gurr,.. the build system went into a POST_APPROVE state and didn't push the
packages 8( the joys of automation.

For the src try here (I threw this up a tempary measure until rawhide updates
again tonight)


-rw-r--r--    1 root     root     12604914 Mar  5 18:29 php-4.1.2-2.src.rpm
[root@parcelfarce incoming]# md5sum php-4.1.2-2.src.rpm
c203cf3edc3372b7601d30cf3b47e4ee  php-4.1.2-2.src.rpm


Comment 7 Geoffrey D. Bennett 2002-03-10 23:51:19 EST
The php-4.1.2-2 RPM still has not appeared in rawhide.
Comment 8 Phil Copeland 2002-03-11 01:43:54 EST
There are issues with the libraries in rawhide which have prevented php being
rebuilt (hurrah for php depending on >30 odd packages that move in flux)

Just grab the srpm from
and recompile it

Remember, rawhide binaries are generally not healthy for your system because
shared library versions keep shifting. Always use the src

Comment 9 Need Real Name 2002-03-11 05:37:06 EST
I'm sorry I've built the php-4.1.2-2.src.rpm already some
days ago but at the moment there is no opportunity to
test it on our production systems.  I expect the problem
to be solved though: in the PHP changelog it is mentioned
as a problem *specific* to php-4.0.6, so upgrading to a
higher version should make it disapear.

One issue with building the php-4.1.2-2.src.rpm is that
there is a dependency on curl-devel >= 7.9 which is not
included in Red Hat 7.2.  If you remove this line
and the "--with-curl" in the configure the RPM  will build
fine.  This dependancy should be taken in account whenever
there is a final RH 7.2 errata to be built !

    Rob van Nieuwkerk
Comment 10 Phil Copeland 2002-03-11 10:43:54 EST
7.2 did ship with curl. Admittidly version 7.8 and php did take advantage of it.
Because of that CURL now has to be supported but 4.1.2 requires version 7.9
(ok, thats what the php package claims it needs)

you should find curl-7.9.3-2.src.rpm in the same dir as the php src rpm
curl needs to be errataed at the same time as php 4.1.2 is errataed

Fun and joy...


Note You need to log in before you can comment on or make changes to this bug.