OK I've narrowed down my problem to:


in extensions.ini

If I comment out that php extension, I'm good. If I don't, I crash when sending HUP signal to parent apache process. I experimented with the order of the extensions.ini file but could not get to work regardless of putting that mhash in the beginning or the end of the file.

On freebsd 7, I've cvsup'd and rebuilt all ports, so I know it's not an 'out of date' kind of thing. Hmm..


On May 20, 2008, at 8:02 AM, Sean C. Farley wrote:

On Mon, 19 May 2008, Randy Bush wrote:

386 very current

i have been unable to get apache not to segv on one server for a while

i tried the php rebuild

i tried clearing obj, full system build, full ports force rebuild, ...

i just tried

If you have a backup of php/extensions.ini from before you did your
updates, it would be worth trying reverting to that, to get the order
you had before that seemed OK.

still coring

but it is nice to know i have company :)

I recall mention on an E-mail list or on IRC of a core dump with PHP due to improper use of putenv(), but I do not remember where. Bug #44836[1]
discusses it.  It seems the patch was reverted, but I see that it is
included as a patch within the ports tree.  You could try to see if
things improve by using the older patch[2] for FreeBSD 7 (and above)

Cc'ing delphij to mention that the patch was reverted in the PHP tree.
Was the patch written for FreeBSD 6?  I noticed that it frees memory
just after the call to putenv().  The is valid for FreeBSD 6 where the
string was duped, but in 7, it follows the POSIX standard of using the
string directly.

 1. http://bugs.php.net/bug.php?id=44836
[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED] "

freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to