2007/9/12, Daniel Brown <parasane@gmail.com>:
> 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.

Thank you but I think it is already there?

<IfModule mod_dir.c>
<IfModule mod_php3.c>
<IfModule mod_php4.c>
DirectoryIndex index.php index.php3 index.html
</IfModule>
<IfModule mod_php5.c>
DirectoryIndex index.php index.php3 index.html
</IfModule>
<IfModule !mod_php4.c>
DirectoryIndex index.php3 index.html
</IfModule>
</IfModule>
<IfModule !mod_php3.c>
<IfModule mod_php4.c>
DirectoryIndex index.php index.html
</IfModule>
<IfModule !mod_php4.c>
DirectoryIndex index.html
</IfModule>
</IfModule>
</IfModule>

Thanks again!

Zbigniew Szalbot

On 9/12/07, Zbigniew Szalbot <zszalbot@gmail.com> wrote:
> 2007/9/12, Daniel Brown <parasane@gmail.com>:
> > 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.
>
> Thank you but I think it is already there?
>
> <IfModule mod_dir.c>
> <IfModule mod_php3.c>
> <IfModule mod_php4.c>
> DirectoryIndex index.php index.php3 index.html
> </IfModule>
> <IfModule mod_php5.c>
> DirectoryIndex index.php index.php3 index.html
> </IfModule>
> <IfModule !mod_php4.c>
> DirectoryIndex index.php3 index.html
> </IfModule>
> </IfModule>
> <IfModule !mod_php3.c>
> <IfModule mod_php4.c>
> DirectoryIndex index.php index.html
> </IfModule>
> <IfModule !mod_php4.c>
> DirectoryIndex index.html
> </IfModule>
> </IfModule>
> </IfModule>
>
> Thanks again!
>
> Zbigniew Szalbot
>

Was it in there before you last started Apache? If not, you
should restart Apache for it to take effect.

--
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....

Hello,

2007/9/12, Daniel Brown <parasane@gmail.com>:
> On 9/12/07, Zbigniew Szalbot <zszalbot@gmail.com> wrote:
> > 2007/9/12, Daniel Brown <parasane@gmail.com>:
> > > 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.
> >
> > Thank you but I think it is already there?
> >
> > <IfModule mod_dir.c>
> > <IfModule mod_php3.c>
> > <IfModule mod_php4.c>
> > DirectoryIndex index.php index.php3 index.html
> > </IfModule>
> > <IfModule mod_php5.c>
> > DirectoryIndex index.php index.php3 index.html
> > </IfModule>
> > <IfModule !mod_php4.c>
> > DirectoryIndex index.php3 index.html
> > </IfModule>
> > </IfModule>
> > <IfModule !mod_php3.c>
> > <IfModule mod_php4.c>
> > DirectoryIndex index.php index.html
> > </IfModule>
> > <IfModule !mod_php4.c>
> > DirectoryIndex index.html
> > </IfModule>
> > </IfModule>
> > </IfModule>
> >
> > Thanks again!
> >
> > Zbigniew Szalbot
> >
>
> Was it in there before you last started Apache? If not, you
> should restart Apache for it to take effect.

Indeed it was. Error log does not show anything special when I run a
php file in browser and it shows directory content.

Thanks!

zbigniew szalbot

On 9/12/07, Zbigniew Szalbot <zszalbot@gmail.com> wrote:
> Hello,
>
> 2007/9/12, Daniel Brown <parasane@gmail.com>:
> > On 9/12/07, Zbigniew Szalbot <zszalbot@gmail.com> wrote:
> > > 2007/9/12, Daniel Brown <parasane@gmail.com>:
> > > > 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.
> > >
> > > Thank you but I think it is already there?
> > >
> > > <IfModule mod_dir.c>
> > > <IfModule mod_php3.c>
> > > <IfModule mod_php4.c>
> > > DirectoryIndex index.php index.php3 index.html
> > > </IfModule>
> > > <IfModule mod_php5.c>
> > > DirectoryIndex index.php index.php3 index.html
> > > </IfModule>
> > > <IfModule !mod_php4.c>
> > > DirectoryIndex index.php3 index.html
> > > </IfModule>
> > > </IfModule>
> > > <IfModule !mod_php3.c>
> > > <IfModule mod_php4.c>
> > > DirectoryIndex index.php index.html
> > > </IfModule>
> > > <IfModule !mod_php4.c>
> > > DirectoryIndex index.html
> > > </IfModule>
> > > </IfModule>
> > > </IfModule>
> > >
> > > Thanks again!
> > >
> > > Zbigniew Szalbot
> > >
> >
> > Was it in there before you last started Apache? If not, you
> > should restart Apache for it to take effect.
>
> Indeed it was. Error log does not show anything special when I run a
> php file in browser and it shows directory content.
>
> Thanks!
>
> zbigniew szalbot
>

Since it loaded after refreshing then, my guess is that it was
cached in your browser. Try creating a brand-new directory with an
index.php file containing only the following:

<? phpinfo(); ?>

When you access that new directory in your web browser, without
calling the index.php file directly, it should show the PHP
information page. If that's the case, then it was almost certainly
just a local browser cache issue.

--
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....

can i ask why you have anything to do with mod_php3 there?

and if you don't plan on trying to use php4 and php5, then remove any
looking for php4 too.

> > <IfModule mod_dir.c>
> > <IfModule mod_php3.c>
> > <IfModule mod_php4.c>
> > DirectoryIndex index.php index.php3 index.html
> > </IfModule>
> > <IfModule mod_php5.c>
> > DirectoryIndex index.php index.php3 index.html
> > </IfModule>
> > <IfModule !mod_php4.c>
> > DirectoryIndex index.php3 index.html
> > </IfModule>
> > </IfModule>
> > <IfModule !mod_php3.c>
> > <IfModule mod_php4.c>
> > DirectoryIndex index.php index.html
> > </IfModule>
> > <IfModule !mod_php4.c>
> > DirectoryIndex index.html
> > </IfModule>
> > </IfModule>
> > </IfModule>

On 9/12/07, Zbigniew Szalbot <zszalbot@gmail.com> wrote:
> Hello,
>
> 2007/9/12, Daniel Brown <parasane@gmail.com>:
> > On 9/12/07, Zbigniew Szalbot <zszalbot@gmail.com> wrote:
> > > 2007/9/12, Daniel Brown <parasane@gmail.com>:
> > > > 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.
> > >
> > > Thank you but I think it is already there?
> > >
> > > <IfModule mod_dir.c>
> > > <IfModule mod_php3.c>
> > > <IfModule mod_php4.c>
> > > DirectoryIndex index.php index.php3 index.html
> > > </IfModule>
> > > <IfModule mod_php5.c>
> > > DirectoryIndex index.php index.php3 index.html
> > > </IfModule>
> > > <IfModule !mod_php4.c>
> > > DirectoryIndex index.php3 index.html
> > > </IfModule>
> > > </IfModule>
> > > <IfModule !mod_php3.c>
> > > <IfModule mod_php4.c>
> > > DirectoryIndex index.php index.html
> > > </IfModule>
> > > <IfModule !mod_php4.c>
> > > DirectoryIndex index.html
> > > </IfModule>
> > > </IfModule>
> > > </IfModule>
> > >
> > > Thanks again!
> > >
> > > Zbigniew Szalbot
> > >
> >
> > Was it in there before you last started Apache? If not, you
> > should restart Apache for it to take effect.
>
> Indeed it was. Error log does not show anything special when I run a
> php file in browser and it shows directory content.
>
> Thanks!
>
> zbigniew szalbot
>

Zbigniew,

Also, check for this line in your httpd.conf file:
<IfModule mod_dir.c>

Make sure index.php is in that list if the entry exists.

--
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....

Hello again,

2007/9/12, Daniel Brown <parasane@gmail.com>:
> > > > <IfModule mod_dir.c>
> > > > <IfModule mod_php3.c>
> > > > <IfModule mod_php4.c>
> > > > DirectoryIndex index.php index.php3 index.html
> > > > </IfModule>
> > > > <IfModule mod_php5.c>
> > > > DirectoryIndex index.php index.php3 index.html
> > > > </IfModule>
> > > > <IfModule !mod_php4.c>
> > > > DirectoryIndex index.php3 index.html
> > > > </IfModule>
> > > > </IfModule>
> > > > <IfModule !mod_php3.c>
> > > > <IfModule mod_php4.c>
> > > > DirectoryIndex index.php index.html
> > > > </IfModule>
> > > > <IfModule !mod_php4.c>
> > > > DirectoryIndex index.html
> > > > </IfModule>
> > > > </IfModule>
> > > > </IfModule>

> Also, check for this line in your httpd.conf file:
> <IfModule mod_dir.c>
>
> Make sure index.php is in that list if the entry exists.

Daniel as you say:
> PHP is properly loading, but your DirectoryIndex is not working.

The only refrences to DirectoryIndex and <IfModule mod_dir.c> are in
the above quoted content in httpd.conf. I will get rid of all php3
entries and let you know if this has solved the problem.

Thank you for your patience!

Zbigniew Szalbot

Hello,

2007/9/12, Zbigniew Szalbot <zszalbot@gmail.com>:
> Hello again,
>
> 2007/9/12, Daniel Brown <parasane@gmail.com>:
> > > > > <IfModule mod_dir.c>
> > > > > <IfModule mod_php3.c>
> > > > > <IfModule mod_php4.c>
> > > > > DirectoryIndex index.php index.php3 index.html
> > > > > </IfModule>
> > > > > <IfModule mod_php5.c>
> > > > > DirectoryIndex index.php index.php3 index.html
> > > > > </IfModule>
> > > > > <IfModule !mod_php4.c>
> > > > > DirectoryIndex index.php3 index.html
> > > > > </IfModule>
> > > > > </IfModule>
> > > > > <IfModule !mod_php3.c>
> > > > > <IfModule mod_php4.c>
> > > > > DirectoryIndex index.php index.html
> > > > > </IfModule>
> > > > > <IfModule !mod_php4.c>
> > > > > DirectoryIndex index.html
> > > > > </IfModule>
> > > > > </IfModule>
> > > > > </IfModule>
>
> > Also, check for this line in your httpd.conf file:
> > <IfModule mod_dir.c>
> >
> > Make sure index.php is in that list if the entry exists.
>
> Daniel as you say:
> > PHP is properly loading, but your DirectoryIndex is not working.
>
> The only refrences to DirectoryIndex and <IfModule mod_dir.c> are in
> the above quoted content in httpd.conf. I will get rid of all php3
> entries and let you know if this has solved the problem.

I took the safe approach and just removed index.php from each
statements, one by one until I was left with none. I was still able to
display httpd://szalbot.homedns.org/test/

Currently I have index.php in mod_php5.c:

<IfModule mod_dir.c>
<IfModule mod_php3.c>
<IfModule mod_php4.c>
DirectoryIndex index.html
</IfModule>
<IfModule mod_php5.c>
DirectoryIndex index.php index.html
</IfModule>
<IfModule !mod_php4.c>
DirectoryIndex index.html
</IfModule>
</IfModule>
<IfModule !mod_php3.c>
<IfModule mod_php4.c>
DirectoryIndex index.html
</IfModule>
<IfModule !mod_php4.c>
DirectoryIndex index.html
</IfModule>
</IfModule>
</IfModule>

Funny thing is that it was never a problem with php 4.7. I actually
changed nothing in httpd.conf between the versions. I installed php5
from ports and during installation of course all references to php4
were replaced with php5 (in httpd.conf).

It is clearly problem with indexes but how and where that is an issue
for me. there is a solution which I could live with. That is I can
create an index.html page which will simply redirect to index.php and
so index-wise everything will work but I would really prefer to find
out what is wrong.

Thanks!

Zbigniew Szalbot

On 9/12/07, Zbigniew Szalbot <zszalbot@gmail.com> wrote:
> Hello,
>
> 2007/9/12, Zbigniew Szalbot <zszalbot@gmail.com>:
> > Hello again,
> >
> > 2007/9/12, Daniel Brown <parasane@gmail.com>:
> > > > > > <IfModule mod_dir.c>
> > > > > > <IfModule mod_php3.c>
> > > > > > <IfModule mod_php4.c>
> > > > > > DirectoryIndex index.php index.php3 index.html
> > > > > > </IfModule>
> > > > > > <IfModule mod_php5.c>
> > > > > > DirectoryIndex index.php index.php3 index.html
> > > > > > </IfModule>
> > > > > > <IfModule !mod_php4.c>
> > > > > > DirectoryIndex index.php3 index.html
> > > > > > </IfModule>
> > > > > > </IfModule>
> > > > > > <IfModule !mod_php3.c>
> > > > > > <IfModule mod_php4.c>
> > > > > > DirectoryIndex index.php index.html
> > > > > > </IfModule>
> > > > > > <IfModule !mod_php4.c>
> > > > > > DirectoryIndex index.html
> > > > > > </IfModule>
> > > > > > </IfModule>
> > > > > > </IfModule>
> >
> > > Also, check for this line in your httpd.conf file:
> > > <IfModule mod_dir.c>
> > >
> > > Make sure index.php is in that list if the entry exists.
> >
> > Daniel as you say:
> > > PHP is properly loading, but your DirectoryIndex is not working.
> >
> > The only refrences to DirectoryIndex and <IfModule mod_dir.c> are in
> > the above quoted content in httpd.conf. I will get rid of all php3
> > entries and let you know if this has solved the problem.
>
> I took the safe approach and just removed index.php from each
> statements, one by one until I was left with none. I was still able to
> display httpd://szalbot.homedns.org/test/
>
> Currently I have index.php in mod_php5.c:
>
> <IfModule mod_dir.c>
> <IfModule mod_php3.c>
> <IfModule mod_php4.c>
> DirectoryIndex index.html
> </IfModule>
> <IfModule mod_php5.c>
> DirectoryIndex index.php index.html
> </IfModule>
> <IfModule !mod_php4.c>
> DirectoryIndex index.html
> </IfModule>
> </IfModule>
> <IfModule !mod_php3.c>
> <IfModule mod_php4.c>
> DirectoryIndex index.html
> </IfModule>
> <IfModule !mod_php4.c>
> DirectoryIndex index.html
> </IfModule>
> </IfModule>
> </IfModule>
>
> Funny thing is that it was never a problem with php 4.7. I actually
> changed nothing in httpd.conf between the versions. I installed php5
> from ports and during installation of course all references to php4
> were replaced with php5 (in httpd.conf).
>
> It is clearly problem with indexes but how and where that is an issue
> for me. there is a solution which I could live with. That is I can
> create an index.html page which will simply redirect to index.php and
> so index-wise everything will work but I would really prefer to find
> out what is wrong.
>
> Thanks!
>
> Zbigniew Szalbot
>

That's not solving the issue, though. That's creating a
workaround for it and ignoring its existence --- and a very hacky
workaround, at that.

There's no need to remove the index.php entries. In fact, quite
the opposite: if Apache doesn't know that it should serve index.php as
an index file, there's no way it will.

Try commenting out the whole block of data you sent to the list
from your httpd.conf file and entering only this instead:

<IfModule mod_dir.c>
DirectoryIndex index.php index.php3 index.html index.htm
</IfModule>

If even that doesn't work, then you don't have mod_dir.so loading
when Apache is started. You can either add that or simply comment out
the entire IfModule section and just simply have DirectoryIndex out in
the open, by itself, which is perfectly safe to do as well.

--
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....

Zbigniew Szalbot wrote:

> It is clearly problem with indexes but how and where that is an issue
> for me. there is a solution which I could live with. That is I can
> create an index.html page which will simply redirect to index.php and
> so index-wise everything will work but I would really prefer to find
> out what is wrong.

Get hold of one of core dumps, and submit it to the PHP developers. They
understand those.



/Per Jessen, Zürich

Jay Blanchard wrote:

>> 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.

I beg to differ. In the past 20 years, I've spent plenty of time
working with core dumps, stand-alone dumps, slip traps and system
traces debugging my own software (running at customer sites) without
the remotest possibility of reproducing a problem on-demand.
If you think a problem must be reproducable for "any development team"
to solve it, you need to try working in a real one. No offence, just
my opinion.

> In order to replicate the issue they have to duplicate the action that
> caused the failure.

Unless you work based on trial&error, there is no real need to replicate
the issue until you feel you may have identified the problem. A core
dump or an strace or some debug output at the right time will have 99%
of the information you need - provided you understand how to read it.
I submit there is generally no need to reproduce a problem in order to
diagnose it. To fix it, yes, it will undoubtedly if you can
reproduce it, but once you've diagnosed it, reproducing it is a
lot easier.

> 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...

Jay, this is the same kind of c... that PHP developers have responded
with in the past. I'm sorry, but IMO that is entirely unprofessional.
OK, so maybe one isn't being paid to write open source software, but
that's no excuse for not being professional about it. IMHO.

What's the purpose of a core dump if it does not provide the key
information for solving a problem? If I still have to isolate and
reproduce the issue in user code, there seems to be very little need for
the core dump, right?


/Per Jessen, Zürich

Per Jessen wrote:
> 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.

Please tell me you're kidding? If you can't provide a piece of code that
always causes the segfault are you seriously expecting the devs to waste
their time trying to find the cause? Talk about a needle in a haystack.

The ease of reproduction is not particularly important, although the
easier the better. The important thing is that every time you run the
script it causes a segfault.

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

To me this comment indicates a lack of experience in software
development with C. Segfaults are a fact of life and it's very difficult
to cover every possible cause, especially when you are using a number of
external libraries. Expecting PHP to be perfect is unrealistic.

The core development team is a limited resource and they need to put
their time where their time provides the most benefit. I'm not saying
they always get this right, but you can't expect them to invest their
time into fixing a problem you've found unless you've done the work
yourself to isolate where the problem is and you have a piece of code
that causes it 100% of the time.

-Stut

--
http://stut.net/

[snip]
I beg to differ. In the past 20 years, I've spent plenty of time
working with core dumps, stand-alone dumps, slip traps and system
traces debugging my own software (running at customer sites) without
the remotest possibility of reproducing a problem on-demand.
If you think a problem must be reproducable for "any development team"
to solve it, you need to try working in a real one. No offence, just
my opinion.
[/snip]

I agree, sometimes you cannot get the actions that caused the issue from
a customer, but in this case we are developers...we are (or should be)
smarter than the average user and should be able to take code that we
are running when the segfault occurs and provide that to the PHP
development team.

It is much easier for any development team when the problem is
reproducible. I have worked and led "real ones" for nearly 30 years (and
several languages) and one of the troubleshooting techniques is to
attempt to reproduce the error.

[snip]
A core dump or an strace or some debug output at the right time will
have 99% of the information you need - provided you understand how to
read it.
I submit there is generally no need to reproduce a problem in order to
diagnose it. To fix it, yes, it will undoubtedly if you can
reproduce it, but once you've diagnosed it, reproducing it is a
lot easier.
[/snip]

Wouldn't it be nice to have 100% of the information? That last 1% may be
the code that caused the problem.

[snip]
> 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...

Jay, this is the same kind of c... that PHP developers have responded
with in the past. I'm sorry, but IMO that is entirely unprofessional.
OK, so maybe one isn't being paid to write open source software, but
that's no excuse for not being professional about it. IMHO.
[/snip]

So given just a clue you can surmise what code the developer wrote, how
s/he used it and how it failed from a general description? As developers
we have a responsibility as well; we must do our part and if that
includes troubleshooting and isolating code that causes a segfault then
so be it. I understand that we sometimes do not do this, and we should
expect that solutions will be more difficult to come by.

[snip]
What's the purpose of a core dump if it does not provide the key
information for solving a problem? If I still have to isolate and
reproduce the issue in user code, there seems to be very little need for
the core dump, right?
[/snip]

Not so. A core dump, as you stated before, gives you most of the
information. Having the code that appeared to have caused the problem is
definitely welcomed. It s to see what was occurring when the
segfault happened. Would you not agree?

I want to make a note here; only if I run the same code over and over
and it causes a segfault every time do I have code that may cause the
issue. If the developer is not the only one testing on the same box then
there could be multiple reasons for the core dump. I would never send a
one-time core dump to the dev team. I would isolate and test my code
again and again to see if the segfault occurred each time. At that point
I would submit the info if there was nothing in the core dump that gave
me a clue as to what was going on.

If you have multiple developers testing on the same platform and
experience a segfault you may never be able to reproduce the problem
because it could be a combination of things that caused the problem to
occur. Giving the core dump data to the development team provides them
valuable information but it may not be a problem easily solved because
there are too many variables to account for.

Stut wrote:

> Please tell me you're kidding? If you can't provide a piece of code
> that always causes the segfault are you seriously expecting the devs
> to waste their time trying to find the cause? Talk about a needle in a
> haystack.
>
> The ease of reproduction is not particularly important, although the
> easier the better. The important thing is that every time you run the
> script it causes a segfault.
>
> > I still maintain it is exceptionally poor show by php to let user
> > code produce segfaults in apache.
>
> To me this comment indicates a lack of experience in software
> development with C.

To let a user script bring down the host environment is just not
acceptable. IMHO.
I've spent my professional life (sofar) doing development in C and
assembler - when your code causes a problem at a customer site in
Japan, you have absolutely zero chance of reproducing the problem -
until you have analysed whatever dumps and system traces you have been
provided with. Maybe you have to set a SLIP trap for producing more
diagnostics, but you can only hope the problem re-occurs.

> Segfaults are a fact of life

Only if you are forced to accept poor programming. I can assure you
that segfaults are not tolerated in a regular production environment.
Segfaults happen in test and development.

> and it's very difficult to cover every possible cause, especially when
> you are using a number of external libraries. Expecting PHP to be
> perfect is unrealistic.

Actually I think the PHP developers should strive for just that. Not to
do so is like the GCC people saying - "well, don't expect us to
generate working code EVERY time" ...


/Per Jessen, Zürich

Per Jessen wrote:

> To let a user script bring down the host environment is just not
> acceptable. IMHO.

Here's an example from this morning - I have a situation where all I
need to do is add a single superfluous double quote, and I get a
segfault. Is that not poor error handling somewhere?




/Per Jessen, Zürich

On Fri, 14 Sep 2007 10:10:09 +0200, Per Jessen <per@computer.org> wrote:
> Per Jessen wrote:
>
>> To let a user script bring down the host environment is just not
>> acceptable. IMHO.
>
> Here's an example from this morning - I have a situation where all I
> need to do is add a single superfluous double quote, and I get a
> segfault. Is that not poor error handling somewhere?
>
>
>
>
> /Per Jessen, Zürich
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php

Would love to see the code that caused this.

dev@lenss.nl wrote:

> On Fri, 14 Sep 2007 10:10:09 +0200, Per Jessen <per@computer.org>
> wrote:
>> Per Jessen wrote:
>>
>>> To let a user script bring down the host environment is just not
>>> acceptable. IMHO.
>>
>> Here's an example from this morning - I have a situation where all I
>> need to do is add a single superfluous double quote, and I get a
>> segfault. Is that not poor error handling somewhere?
>>
>
> Would love to see the code that caused this.

http://jessen.ch/files/php-problem-sep2007.tar.gz


/Per Jessen, Zürich

Per Jessen wrote:
>> Segfaults are a fact of life
>
> Only if you are forced to accept poor programming. I can assure you
> that segfaults are not tolerated in a regular production environment.
> Segfaults happen in test and development.

I agree with you for the most part, but there are several points that
need to be made.

First of all you need to remember that you are talking about an open
source project. I know that's no excuse for "poor programming" as you
call it, but it's also unreasonable to expect perfect code.

Secondly you need to clarify what you actually want. When PHP segfaults
I doubt it's actually PHP that's doing it, it's more likely to be one of
the extensions being used. This is what I meant when I said segfaults
are a fact of life. You're dealing with a system that can be compiled
with arbitrary code from any source. While it's not out of the question
I very much doubt there are any cases where an extra double quote will
cause a segfault in the engine itself.

The code you sent in response to dev-at-lenss.nl doesn't really say
where the problem is, but it seems to be all about XSL which is not
handled by PHP, it's done by a PHP extension.

>> and it's very difficult to cover every possible cause, especially when
>> you are using a number of external libraries. Expecting PHP to be
>> perfect is unrealistic.
>
> Actually I think the PHP developers should strive for just that. Not to
> do so is like the GCC people saying - "well, don't expect us to
> generate working code EVERY time" ...

I believe that the core PHP devs do everything they can to ensure the
reliability of the core PHP code. Unfortunately the same cannot be said
for the multitude of extension developers out there.

The Zend engine does generate "working" code every time in much the same
way as GCC does. If that code uses extensions then the engine has no way
of protecting against those extensions causing segfaults.

To return to the original point, in a commercial environment it is
perfectly reasonable to expect developers to spend time hunting down the
cause of a segfault (or other bug). It is not reasonable to expect the
same from a volunteer-driven development team. As has previously been
mentioned, requiring a simple script that reproduces the problem every
time it's executed is pretty standard.

One final note... if you've spent "professional life (sofar) doing
development in C and assembler" why aren't you digging into the source
code, fixing the problems and submitting patches rather than
complaining? That, after all, is what open source projects like PHP are
all about.

-Stut

--
http://stut.net/

On Fri, 14 Sep 2007 11:09:36 +0200, Per Jessen <per@computer.org> wrote:
> dev@lenss.nl wrote:
>
>> On Fri, 14 Sep 2007 10:10:09 +0200, Per Jessen <per@computer.org>
>> wrote:
>>> Per Jessen wrote:
>>>
>>>> To let a user script bring down the host environment is just not
>>>> acceptable. IMHO.
>>>
>>> Here's an example from this morning - I have a situation where all I
>>> need to do is add a single superfluous double quote, and I get a
>>> segfault. Is that not poor error handling somewhere?
>>>
>>
>> Would love to see the code that caused this.
>
> http://jessen.ch/files/php-problem-sep2007.tar.gz
>
>
> /Per Jessen, Zürich
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php

Don't really see what i has to do with a double quote.

When i run the script it segfaults on windows with php 4.x and 5.x. That's
weird.
On linux the script runs fine.

On Fri, 14 Sep 2007 11:09:36 +0200, Per Jessen <per@computer.org> wrote:
> dev@lenss.nl wrote:
>
>> On Fri, 14 Sep 2007 10:10:09 +0200, Per Jessen <per@computer.org>
>> wrote:
>>> Per Jessen wrote:
>>>
>>>> To let a user script bring down the host environment is just not
>>>> acceptable. IMHO.
>>>
>>> Here's an example from this morning - I have a situation where all I
>>> need to do is add a single superfluous double quote, and I get a
>>> segfault. Is that not poor error handling somewhere?
>>>
>>
>> Would love to see the code that caused this.
>
> http://jessen.ch/files/php-problem-sep2007.tar.gz
>
>
> /Per Jessen, Zürich
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php

It's the call to virtual() that causes the segfault on windows.