From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) 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: Usually. 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.
Created attachment 45399 [details] gdb backtraces after apache segfaults
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)"
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
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 Phil =--=
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 .. greetings, Rob van Nieuwkerk
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) ftp://ftp.linux.org.uk/pub/linux/incoming/php-4.1.2-2.src.rpm -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 appologies... Phil =--=
The php-4.1.2-2 RPM still has not appeared in rawhide.
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 ftp://ftp.linux.org.uk/pub/linux/incoming/php-4.1.2-2.src.rpm and recompile it Remember, rawhide binaries are generally not healthy for your system because shared library versions keep shifting. Always use the src Phil =--=
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 ! greetings, Rob van Nieuwkerk
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... Phil =--=