Dear all,

I hope you can me. I am running FreeBSD 6.2 and I decided to
upgrade from php 4.4.7_1 to php5-5.2.3_1. However, after removing php4
and installing php5 and php5-extensions I am unable to start apache.

php -v:

PHP 5.2.3 with Suhosin-Patch 0.9.6.2 (cli) (built: Sep 12 2007 08:59:52)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
Segmentation fault (core dumped)

pkg_info | grep php5
php5-5.2.3_1 PHP Scripting Language (Apache Module and CLI)
php5-bcmath-5.2.3_1 The bcmath shared extension for php
php5-bz2-5.2.3_1 The bz2 shared extension for php
php5-calendar-5.2.3_1 The calendar shared extension for php
php5-ctype-5.2.3_1 The ctype shared extension for php
php5-curl-5.2.3_1 The curl shared extension for php
php5-dbase-5.2.3_1 The dbase shared extension for php
php5-dom-5.2.3_1 The dom shared extension for php
php5-exif-5.2.3_1 The exif shared extension for php
php5-extensions-1.1 A "meta-port" to install PHP extensions
php5-ftp-5.2.3_1 The ftp shared extension for php
php5-gd-5.2.3_1 The gd shared extension for php
php5-gettext-5.2.3_1 The gettext shared extension for php
php5-gmp-5.2.3_1 The gmp shared extension for php
php5-iconv-5.2.3_1 The iconv shared extension for php
php5-imap-5.2.3_1 The imap shared extension for php
php5-mbstring-5.2.3_1 The mbstring shared extension for php
php5-mcrypt-5.2.3_1 The mcrypt shared extension for php
php5-mhash-5.2.3_1 The mhash shared extension for php
php5-mysql-5.2.3_1 The mysql shared extension for php
php5-mysqli-5.2.3_1 The mysqli shared extension for php
php5-openssl-5.2.3_1 The openssl shared extension for php
php5-pcre-5.2.3_1 The pcre shared extension for php
php5-pdo-5.2.3_1 The pdo shared extension for php
php5-pdo_sqlite-5.2.3_1 The pdo_sqlite shared extension for php
php5-posix-5.2.3_3 The posix shared extension for php
php5-pspell-5.2.3_1 The pspell shared extension for php
php5-session-5.2.3_1 The session shared extension for php
php5-simplexml-5.2.3_1 The simplexml shared extension for php
php5-soap-5.2.3_1 The soap shared extension for php
php5-sockets-5.2.3_1 The sockets shared extension for php
php5-spl-5.2.3_1 The spl shared extension for php
php5-sqlite-5.2.3_1 The sqlite shared extension for php
php5-tokenizer-5.2.3_1 The tokenizer shared extension for php
php5-xml-5.2.3_1 The xml shared extension for php
php5-xmlreader-5.2.3_1 The xmlreader shared extension for php
php5-xmlrpc-5.2.3_1 The xmlrpc shared extension for php
php5-xmlwriter-5.2.3_1 The xmlwriter shared extension for php
php5-zlib-5.2.3_1 The zlib shared extension for php

httpd -v
Server version: Apache/1.3.39 (Unix)
Server built: Sep 11 2007 20:48:37

Many thanks for your !

Zbigniew Szalbot

> Dear all,
>
> I hope you can me. I am running FreeBSD 6.2 and I decided to
> upgrade from php 4.4.7_1 to php5-5.2.3_1. However, after removing php4
> and installing php5 and php5-extensions I am unable to start apache.

What do the Apache error logs say?

Edward

Hello,

2007/9/12, Edward Kay <edward@labhut.com>:
>
> > Dear all,
> >
> > I hope you can me. I am running FreeBSD 6.2 and I decided to
> > upgrade from php 4.4.7_1 to php5-5.2.3_1. However, after removing php4
> > and installing php5 and php5-extensions I am unable to start apache.
>
> What do the Apache error logs say?

Nothing that would be of :

httpd-error.log
[Wed Sep 12 09:04:17 2007] [notice] mod_security/1.9.4 configured

A new such line is added when I try to start apache. Apache does not
start even when I use non-ssl option (apachectl start).

messages:
Sep 12 12:04:44 szalbot kernel: pid 26602 (httpd), uid 0: exited on
signal 11 (core dumped)

Many thanks!

Zbigniew Szalbot wrote:

> Hello,
>
> 2007/9/12, Edward Kay <edward@labhut.com>:
>>
>> What do the Apache error logs say?
>
> Nothing that would be of :
>
> httpd-error.log
> [Wed Sep 12 09:04:17 2007] [notice] mod_security/1.9.4 configured
>
> A new such line is added when I try to start apache. Apache does not
> start even when I use non-ssl option (apachectl start).
>
> messages:
> Sep 12 12:04:44 szalbot kernel: pid 26602 (httpd), uid 0: exited on
> signal 11 (core dumped)

Migrating from v4 to v5 is not necessarily straight forward.
Depending on what features you've used, you may have to rewrite some of
your code. For instance, we used the xslt sablotron interface, which
no longer exists in php5. Had to rewrite, which as it turns out was
not too much effort, but I'm sure there are other more complex
examples.


/Per Jessen, Zürich

Hi there,

2007/9/12, Per Jessen <per@computer.org>:
> Zbigniew Szalbot wrote:
>
> > Hello,
> >
> > 2007/9/12, Edward Kay <edward@labhut.com>:
> >>
> >> What do the Apache error logs say?
> >
> > Nothing that would be of :
> >
> > httpd-error.log
> > [Wed Sep 12 09:04:17 2007] [notice] mod_security/1.9.4 configured
> >
> > A new such line is added when I try to start apache. Apache does not
> > start even when I use non-ssl option (apachectl start).
> >
> > messages:
> > Sep 12 12:04:44 szalbot kernel: pid 26602 (httpd), uid 0: exited on
> > signal 11 (core dumped)
>
> Migrating from v4 to v5 is not necessarily straight forward.
> Depending on what features you've used, you may have to rewrite some of
> your code. For instance, we used the xslt sablotron interface, which
> no longer exists in php5. Had to rewrite, which as it turns out was
> not too much effort, but I'm sure there are other more complex
> examples.

No, basically I just use wordpress on this site and that's all. No
fancy or advanced scripting, etc. It is family machine for family
issues. I can try and go back to v4 but I do think v5 should work just
as fine. At least I hope so.

Thank you!

Zbigniew Szalbot wrote:

> No, basically I just use wordpress on this site and that's all. No
> fancy or advanced scripting, etc. It is family machine for family
> issues. I can try and go back to v4 but I do think v5 should work just
> as fine. At least I hope so.

Hi Zbigniew

Maybe it's worth doing some googling for wordpress and php5? If it's
not your code, it's not easy to debug. I have seen the apache core
dump many times, sometimes caused by obvious errors, other times by
something obscure and difficult to find.



/Per Jessen, Zürich

Zbigniew Szalbot wrote:
> Hi there,
>
> No, basically I just use wordpress on this site and that's all. No
> fancy or advanced scripting, etc. It is family machine for family
> issues. I can try and go back to v4 but I do think v5 should work just
> as fine. At least I hope so.

Does phpinfo work? What does it say?

Also, when you have problems like this, he best to do is put error
reporting to E_ALL and display_errors=on.

--
21:50:04 up 2 days, 9:07, 0 users, load average: 0.92, 0.37, 0.18
---------------------------------------------------------
Lic. Martín Marqués | SELECT 'mmarques' ||
Centro de Telemática | '@' || 'unl.edu.ar';
Universidad Nacional | DBA, Programador,
del Litoral | Administrador
---------------------------------------------------------

Per Jessen wrote:
> Zbigniew Szalbot wrote:
>
>> No, basically I just use wordpress on this site and that's all. No
>> fancy or advanced scripting, etc. It is family machine for family
>> issues. I can try and go back to v4 but I do think v5 should work just
>> as fine. At least I hope so.
>
> Hi Zbigniew
>
> Maybe it's worth doing some googling for wordpress and php5? If it's
> not your code, it's not easy to debug. I have seen the apache core
> dump many times, sometimes caused by obvious errors, other times by
> something obscure and difficult to find.

Come on guys, use your heads. PHP is segfaulting when trying to display
its version number - that's not going to have anything to do with Wordpress.

To the OP: This probably means you've got a rogue extension in the mix.
Edit /usr/local/etc/php/extensions.ini and put a # in front of every
line. Try php -v again. If it works then you need to uncomment (remove
the #) each line in that file one by one checking php -v each time until
you find the one that's a problem.

If it's an extension you need I suggest you uninstall and rebuild it. If
not then just leave it commented and move on to the next.

If php -v still segfaults with all the extensions disabled then you need
to uninstall PHP and all the extensions completely and start again
because something obviously went wrong when you built them.

-Stut

--
http://stut.net/

Stut wrote:

>> Hi Zbigniew
>>
>> Maybe it's worth doing some googling for wordpress and php5? If it's
>> not your code, it's not easy to debug. I have seen the apache core
>> dump many times, sometimes caused by obvious errors, other times by
>> something obscure and difficult to find.
>
> Come on guys, use your heads. PHP is segfaulting when trying to
> display its version number - that's not going to have anything to do
> with Wordpress.

Uh, how do know you it's do with the version-number?? Did I miss that
posting?

Anyway, I think it's exceptionally poor show by php to cause a segfault,
probably due to user code. I know it does it every now and then, and
nobody has ever been interested in looking at the core dump.


/Per Jessen, Zürich

On 9/12/07, Per Jessen <per@computer.org> wrote:
> Migrating from v4 to v5 is not necessarily straight forward.
> Depending on what features you've used, you may have to rewrite some of
> your code. For instance, we used the xslt sablotron interface, which
> no longer exists in php5. Had to rewrite, which as it turns out was
> not too much effort, but I'm sure there are other more complex
> examples.

While that's probable true, it wouldn't stop Apache from loading.
At the far outside realm of possibility, user code could cause PHP to
segfault and crash Apache, but when the httpd daemon is loading, it's
not scanning the user scripts.

Zbigniew, when you're checking the version number, keep in mind
that it's only for the CLI --- completely different from the Apache
module. Did you upgrade Apache in the process? Because the core that
was dumped was the Apache server's binary (httpd), which may indicate
that it's pure coincidence with the PHP version upgrade.

--
Daniel P. Brown
[office] (570-) 587-7080 Ext. 272
[mobile] (570-) 766-8107

Give a man a fish, he'll eat for a day. Then you'll find out he was
allergic and is hospitalized. See? No good deed goes unpunished....

[snip]
Anyway, I think it's exceptionally poor show by php to cause a segfault,
probably due to user code. I know it does it every now and then, and
nobody has ever been interested in looking at the core dump.
[/snip]

The Dev team looks at core dumps all of the time to try to figure out
bugs and other problems.

On 9/12/07, Daniel Brown <parasane@gmail.com> wrote:
> On 9/12/07, Per Jessen <per@computer.org> wrote:
> > Migrating from v4 to v5 is not necessarily straight forward.
> > Depending on what features you've used, you may have to rewrite some of
> > your code. For instance, we used the xslt sablotron interface, which
> > no longer exists in php5. Had to rewrite, which as it turns out was
> > not too much effort, but I'm sure there are other more complex
> > examples.
>
> While that's probable true, it wouldn't stop Apache from loading.
> At the far outside realm of possibility, user code could cause PHP to
> segfault and crash Apache, but when the httpd daemon is loading, it's
> not scanning the user scripts.
>
> Zbigniew, when you're checking the version number, keep in mind
> that it's only for the CLI --- completely different from the Apache
> module. Did you upgrade Apache in the process? Because the core that
> was dumped was the Apache server's binary (httpd), which may indicate
> that it's pure coincidence with the PHP version upgrade.
>
> --
> Daniel P. Brown
> [office] (570-) 587-7080 Ext. 272
> [mobile] (570-) 766-8107
>
> Give a man a fish, he'll eat for a day. Then you'll find out he was
> allergic and is hospitalized. See? No good deed goes unpunished....
>

Okay, I just re-read the original post and I see that the CLI is
actually segfault'ing, too. I should really finish my first cup of
coffee before attempting to reply to the list.

Are you using eAccelerator by chance? I have that on a box with
5.0.4, but noticed problems with that when I used it in combination
with 5.2.3 (among other issues).

--
Daniel P. Brown
[office] (570-) 587-7080 Ext. 272
[mobile] (570-) 766-8107

Give a man a fish, he'll eat for a day. Then you'll find out he was
allergic and is hospitalized. See? No good deed goes unpunished....

Per Jessen wrote:
> Stut wrote:
>
>>> Hi Zbigniew
>>>
>>> Maybe it's worth doing some googling for wordpress and php5? If it's
>>> not your code, it's not easy to debug. I have seen the apache core
>>> dump many times, sometimes caused by obvious errors, other times by
>>> something obscure and difficult to find.
>> Come on guys, use your heads. PHP is segfaulting when trying to
>> display its version number - that's not going to have anything to do
>> with Wordpress.
>
> Uh, how do know you it's do with the version-number?? Did I miss that
> posting?

From the original post...

php -v:

PHP 5.2.3 with Suhosin-Patch 0.9.6.2 (cli) (built: Sep 12 2007 08:59:52)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
Segmentation fault (core dumped)

> Anyway, I think it's exceptionally poor show by php to cause a segfault,
> probably due to user code. I know it does it every now and then, and
> nobody has ever been interested in looking at the core dump.

This will have nothing to do with user code since no user code is
involved in displaying the version info. It's most likely a problem with
mixed version numbers, or possibly (but unlikely) a configuration issue.
If there's an auto_prepend_file or auto_append_file in the configuration
that may be loaded by php -v, I'm not sure.

Blaming PHP for this is like blaming Microsoft because Photoshop crashed
on a Windows machine. It's possible PHP is to blame but there is a whole
stack of other considerations to go through before coming to that
conclusion.

-Stut

--
http://stut.net/

Per Jessen wrote:
> Uh, how do know you it's do with the version-number?? Did I miss that
> posting?
>

Not necessarily to do with the version number itself - it's that PHP is
dying before having actually done anything - it never gets to any PHP code.

From the first post - the last line of what I pasted below:
> php -v:
>
> PHP 5.2.3 with Suhosin-Patch 0.9.6.2 (cli) (built: Sep 12 2007 08:59:52)
> Copyright (c) 1997-2007 The PHP Group
> Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
> Segmentation fault (core dumped)

In my experience, the Suhosin patch (while excellent for security)
caused significant instability in several modules. I ended up having to
scrap it. (It may not have been the patch - it could easily have been
several of the PECL modules we were using. Regardless, they didn't
segfault without the Suhosin patch.)

If possible, you could try building without the patch.



Assuming your machine isn't overclocked and has been tested for hardware
problems...

If the version of PHP you're using is a binary package, you should
probably generate a backtrace from the core that was dumped and report
it as a bug to the provider of that binary. The same goes if it was
built as a FreeBSD port - they should probably know that their default
port builds are segfaulting.

I think Stut's advice for troubleshooting is a good path to take as well.

jon

Per Jessen wrote:
>>> Maybe it's worth doing some googling for wordpress and php5? If it's
>>> not your code, it's not easy to debug. I have seen the apache core
>>> dump many times, sometimes caused by obvious errors, other times by
>>> something obscure and difficult to find.
>> Come on guys, use your heads. PHP is segfaulting when trying to
>> display its version number - that's not going to have anything to do
>> with Wordpress.
>
> Uh, how do know you it's do with the version-number?? Did I miss that
> posting?
>
> Anyway, I think it's exceptionally poor show by php to cause a segfault,
> probably due to user code. I know it does it every now and then, and
> nobody has ever been interested in looking at the core dump.

Zbigniew has not actually managed to get Apache started with PHP installed so
trying to debug stuff running in PHP is a little pointless.

Zbigniew - It is most likely one of the extensions is not able to load. I used
to get the same problem with Windows, but without a seg fault nowadays - just
a 'can't start'.

--
Lester Caine - G8HFL
-----------------------------
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird - http://www.firebirdsql.org/index.php

Jon Anderson wrote:
> If the version of PHP you're using is a binary package, you should
> probably generate a backtrace from the core that was dumped and report
> it as a bug to the provider of that binary. The same goes if it was
> built as a FreeBSD port - they should probably know that their default
> port builds are segfaulting.

I agree, except that you need to isolate whether it's an extension
causing the segfault or PHP itself. I'd bet lunch on it being an extension.

-Stut

--
http://stut.net/

I have the same problem with PHP-5.2.3 on my freebsd 6.2. After commenting
recode, sockets, ming, sysvshm modules, there were no more core dumps. So,
you have to comment the sockets modules in extension.ini and everything will
work fine.

Daniel Brown wrote:

> On 9/12/07, Per Jessen <per@computer.org> wrote:
>> Migrating from v4 to v5 is not necessarily straight forward.
>> Depending on what features you've used, you may have to rewrite some
>> of
>> your code. For instance, we used the xslt sablotron interface, which
>> no longer exists in php5. Had to rewrite, which as it turns out was
>> not too much effort, but I'm sure there are other more complex
>> examples.
>
> While that's probable true, it wouldn't stop Apache from loading.
> At the far outside realm of possibility, user code could cause PHP to
> segfault and crash Apache, but when the httpd daemon is loading, it's
> not scanning the user scripts.

Sorry, I have to disagree strongly here. I have seen apache core dump
many times due to PHP user code. I've also opened bug-reports based on
such core-dumps, but the PHP developer community is not
interested/capable in debugging in that fashion, IMHO.


/Per Jessen, Zürich

Lester Caine wrote:

>> Anyway, I think it's exceptionally poor show by php to cause a
>> segfault,
>> probably due to user code. I know it does it every now and then, and
>> nobody has ever been interested in looking at the core dump.
>
> Zbigniew has not actually managed to get Apache started with PHP
> installed so trying to debug stuff running in PHP is a little
> pointless.

You don't actually need anything running to debug it. There is a core
dump, that's plenty of diagnostics.


/Per Jessen, Zürich

On 9/12/07, Per Jessen <per@computer.org> wrote:
> Sorry, I have to disagree strongly here. I have seen apache core dump
> many times due to PHP user code. I've also opened bug-reports based on
> such core-dumps, but the PHP developer community is not
> interested/capable in debugging in that fashion, IMHO.

Right, and I'll agree with you that user code can cause that,
which I mentioned. However, in the context of this issue, it's when
Apache is first starting, prior to ever even being requested to serve
the content. Hence my assertion.

--
Daniel P. Brown
[office] (570-) 587-7080 Ext. 272
[mobile] (570-) 766-8107

Give a man a fish, he'll eat for a day. Then you'll find out he was
allergic and is hospitalized. See? No good deed goes unpunished....

Stut wrote:

>> Anyway, I think it's exceptionally poor show by php to cause a
>> segfault, probably due to user code. ÂI know it does it every now and
>> then, and nobody has ever been interested in looking at the core
>> dump.
>
> This will have nothing to do with user code since no user code is
> involved in displaying the version info. It's most likely a problem
> with mixed version numbers, or possibly (but unlikely) a configuration
> issue. If there's an auto_prepend_file or auto_append_file in the
> configuration that may be loaded by php -v, I'm not sure.
>
> Blaming PHP for this is like blaming Microsoft because Photoshop
> crashed on a Windows machine. It's possible PHP is to blame but there
> is a whole stack of other considerations to go through before coming
> to that conclusion.

Stut, put this problem aside for a sec, and let me ask this - if I can
produce an apache core-dump using vanilla apache, vanilla php (even
with no extensions if you want) and a PHP script, you'll get someone to
debug it? (I cannot promise a easily reproducable problem, just the
core-dump, and a few hundred lines of script)
FYI, I've tried that before, and the PHP developers are not interested
and/or they do not work with core dumps.

I still maintain it is exceptionally poor show by php to let user code
produce segfaults in apache.

Here's a brief excerpt from a recent apache error-log:

[Thu Aug 30 12:31:20 2007] [notice] child pid 18836 exit signal
Segmentation fault (11)
[Fri Sep 07 10:09:22 2007] [notice] child pid 2634 exit signal
Segmentation fault (11)
[Fri Sep 07 12:25:07 2007] [notice] child pid 18835 exit signal
Segmentation fault (11)
[Fri Sep 07 12:26:10 2007] [notice] child pid 18834 exit signal
Segmentation fault (11)
[Fri Sep 07 12:26:48 2007] [notice] child pid 21729 exit signal
Segmentation fault (11)
[Fri Sep 07 17:18:55 2007] [notice] child pid 18647 exit signal
Segmentation fault (11)
[Fri Sep 07 21:04:45 2007] [notice] child pid 20318 exit signal
Segmentation fault (11)
[Fri Sep 07 21:04:54 2007] [notice] child pid 18403 exit signal
Segmentation fault (11)
[Sun Sep 09 17:43:26 2007] [notice] child pid 18826 exit signal
Segmentation fault (11)
[Sun Sep 09 17:43:53 2007] [notice] child pid 18827 exit signal
Segmentation fault (11)
[Sun Sep 09 17:44:10 2007] [notice] child pid 18825 exit signal
Segmentation fault (11)
[Sun Sep 09 17:45:08 2007] [notice] child pid 18447 exit signal
Segmentation fault (11)
[Sun Sep 09 17:45:24 2007] [notice] child pid 18785 exit signal
Segmentation fault (11)
[Sun Sep 09 17:46:06 2007] [notice] child pid 25399 exit signal
Segmentation fault (11)
[Mon Sep 10 15:18:52 2007] [notice] child pid 28626 exit signal
Segmentation fault (11)
[Mon Sep 10 15:19:22 2007] [notice] child pid 28608 exit signal
Segmentation fault (11)
[Mon Sep 10 15:20:10 2007] [notice] child pid 28856 exit signal
Segmentation fault (11)
[Mon Sep 10 15:20:12 2007] [notice] child pid 28605 exit signal
Segmentation fault (11)
[Mon Sep 10 15:23:07 2007] [notice] child pid 28607 exit signal
Segmentation fault (11)
[Mon Sep 10 18:31:39 2007] [notice] child pid 20378 exit signal
Segmentation fault (11)


These were all caused by PHP user code with PHP5 and apache22.



/Per Jessen, Zürich

Jay Blanchard wrote:

> [snip]
> Anyway, I think it's exceptionally poor show by php to cause a
> segfault,
> probably due to user code. I know it does it every now and then, and
> nobody has ever been interested in looking at the core dump.
> [/snip]
>
> The Dev team looks at core dumps all of the time to try to figure out
> bugs and other problems.

Whenever I've reported a core-dump (which I've stopped doing), nothing's
been done about it unless I've been able to produce a short script to
reproduce.


/Per Jessen, Zürich

[snip]
> [snip]
> Anyway, I think it's exceptionally poor show by php to cause a
> segfault,
> probably due to user code. I know it does it every now and then, and
> nobody has ever been interested in looking at the core dump.
> [/snip]
>
> The Dev team looks at core dumps all of the time to try to figure out
> bugs and other problems.

Whenever I've reported a core-dump (which I've stopped doing), nothing's
been done about it unless I've been able to produce a short script to
reproduce.
[/snip]

That is to be expected and is standard operating procedure for any
development team. In order to replicate the issue they have to duplicate
the action that caused the failure. You see that time and again on this
list as well....without the offending action all we can do is attempt to
guess at what was going on at the time of the failure. Diligent
trouble-shooting on your part would have gotten a much better response.
You could have likely isolated the code that caused the core dump (just
as we isolate problem code on this list...see yesterday's "SEARCHING for
an answer" thread), provided that to the dev team (as I have done
before) and gotten a response.

Dear all,

2007/9/12, Lester Caine <lester@lsces.co.uk>:
> Per Jessen wrote:
> >>> Maybe it's worth doing some googling for wordpress and php5? If it's
> >>> not your code, it's not easy to debug. I have seen the apache core
> >>> dump many times, sometimes caused by obvious errors, other times by
> >>> something obscure and difficult to find.
> >> Come on guys, use your heads. PHP is segfaulting when trying to
> >> display its version number - that's not going to have anything to do
> >> with Wordpress.
> >
> > Uh, how do know you it's do with the version-number?? Did I miss that
> > posting?
> >
> > Anyway, I think it's exceptionally poor show by php to cause a segfault,
> > probably due to user code. I know it does it every now and then, and
> > nobody has ever been interested in looking at the core dump.
>
> Zbigniew has not actually managed to get Apache started with PHP installed so
> trying to debug stuff running in PHP is a little pointless.
>
> Zbigniew - It is most likely one of the extensions is not able to load. I used
> to get the same problem with Windows, but without a seg fault nowadays - just
> a 'can't start'.

First of all - allow me to thank numerous people who tried to !
Thanks to all of you!

I thought the idea of testing php extensions to see which ones result
in segmentation faults was a very good one indeed. Yes, there is no
scripting issue here. I am unable to even start apache so whatever
scripts I may have, it does not really matter. I am not able to go
very far.

So I commented out all extensions and then brought them in one by one.
The one which was causing core dumps was simplexml.so. I had a few
others that I had to comment as otherwise they were giving me trouble
(because of the simplexml being commented out I guess): pdo.so,
pdo_sqlite.so, spl.so, mysqli.so, sqlite.so.

I am not really worried about these. I am not really sure if I will
ever need them. So fine for the time being. php -v does not produce
core dumps and I can start apache.

There's only one problem left to be solved. After the upgrade php
scripts behave as if they were not recognized. I made a test and put a
standard index.html file in a directory, called a browser and the page
was displayed properly. I then changed the page name to index.php and
ran the browser again. This time the directory content was displayed,
showing the index.php file present in it (it wasn't parsed by the
browser). When I reloaded, the page content was finally displayed in a
browser.

So in other words it seems as if the "php" page was not properly
parsed at first. It happens the same way with my wordpress family
blog. It just shows directory content and when I click refresh
index.php is called into the broser. But links to further php pages
result in directory being shown again.

I do have:
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps
inside httpd.conf.

Thoughts anyone? Again thank you so much for so many responses. I read
them all and they were very ful!

Zbigniew Szalbot

On 9/12/07, Zbigniew Szalbot <zszalbot@gmail.com> wrote:
> There's only one problem left to be solved. After the upgrade php
> scripts behave as if they were not recognized. I made a test and put a
> standard index.html file in a directory, called a browser and the page
> was displayed properly. I then changed the page name to index.php and
> ran the browser again. This time the directory content was displayed,
> showing the index.php file present in it (it wasn't parsed by the
> browser). When I reloaded, the page content was finally displayed in a
> browser.
>
> So in other words it seems as if the "php" page was not properly
> parsed at first. It happens the same way with my wordpress family
> blog. It just shows directory content and when I click refresh
> index.php is called into the broser. But links to further php pages
> result in directory being shown again.
>
> I do have:
> AddType application/x-httpd-php .php
> AddType application/x-httpd-php-source .phps
> inside httpd.conf.
>
> Thoughts anyone? Again thank you so much for so many responses. I read
> them all and they were very ful!

Add index.php to your DirectoryIndex area of httpd.conf and that
will fix it.

--
Daniel P. Brown
[office] (570-) 587-7080 Ext. 272
[mobile] (570-) 766-8107

Give a man a fish, he'll eat for a day. Then you'll find out he was
allergic and is hospitalized. See? No good deed goes unpunished....