Bug 6137

Summary:	httpd processes segfaulting when using php3 module and postgresql
Product:	[Retired] Red Hat Linux	Reporter:	chris
Component:	mod_php3	Assignee:	Preston Brown <pbrown>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.1
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2000-01-14 02:14:37 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description chris 1999-10-20 13:49:12 UTC

(At this stage I don't have a lot of information to deliver
on this one; I'll add further details as I track it down.
I'd appreciate a note if this has already been addressed
and I cant find it in bugzilla.)

We have a web-application using apache/php3/postgresql
(also python, but the python parts dont give us any
trouble).

Occasionally, but frequent enough that I can repeat it, an
access to a page (in php3, with some postgresql queries)
will cause the httpd process to segfault. When this
happens, the rest of the httpd processes also segfault. As
the processes die, the master process respawns then, and it
appears that once this has happened with all the processes,
its stable again for some time before the phenomenon
happens again.

This happens on a redhat-6.0 system as well, both 6.0 and
6.1 with the latest updates.

(Will be doing what we can this end to isolate the problem,
perhaps giving you a short segment of code that exhibits
the fault. Any recommendations on debugging options to turn
on, etc, in order to isolate the fault will be gratefully
received).

------- Additional Comments From   10/20/99 18:16 -------
The effect of the bug was not quite like I described above: If I
access a php3 page with the postgres queries, it will crash every
/third/ time /after/ the script runs. The frequency might have
something to do with the number of queries in the script.

Also, I've managed to stop the crashes happening with judicious use
of pg_free_result. The documententation indicates that using
pg_free_result is optional, but it seems to stop the crashes.

I believe now that the PostGreSQL connector for php3 is buggy, not
freeing the result buffers properly when the script terminates.

Comment 1 chris 1999-10-20 22:16:59 UTC

The effect of the bug was not quite like I described above: If I
access a php3 page with the postgres queries, it will crash every
/third/ time /after/ the script runs. The frequency might have
something to do with the number of queries in the script.

Also, I've managed to stop the crashes happening with judicious use
of pg_free_result. The documententation indicates that using
pg_free_result is optional, but it seems to stop the crashes.

I believe now that the PostGreSQL connector for php3 is buggy, not
freeing the result buffers properly when the script terminates.

Comment 2 chris 1999-10-26 13:44:59 UTC

Okay... just did a bit more experimenting, and it seems to have
nothing to do with postgresql, but simply the date function:

If I do this:
$thingy = 940739400;
$return_time = date("M j G:i", $thingy);

The httpd process will crash after the web page is serverd. If I
comment out just the 'date' statement, it doesnt crash (doesnt
display the date either :) If I wind the time back just a tad (in
fact, before Sunday UTC), it works again.

Different compiled versions of apache (the sample above was a compile
from scratch), start crashing at different values. (The default
redhat-6.1 shipment of apache crashes even before that Sunday; but
its too late at night for me to figure out what date exactly... I
don't think its that important anyway :)

Comment 3 chriscog 1999-10-27 06:55:59 UTC

Its a bug in PHP3 3.0.12. Viz: http://bugs.php.net/bugs.php3?id=2397

Sorry for filling up your disk, folks :)

Comment 4 Preston Brown 1999-10-27 15:08:59 UTC

not at all.  you did very thorough research on this one and we are
appreciative of your help.

Comment 5 Preston Brown 2000-01-14 02:14:59 UTC

fixed in next release (which will include 3.0.14)