php-general Digest 14 Sep 2007 13:11:02 -0000 Issue 5018
Topics (messages 262096 through 262110):
[EMAIL PROTECTED]
262096 by: Teo Mattiozzi
Re: Preventing Access to Private Files
262097 by: Chris
Re: PHP 5.2.3 - Segmentation fault (core dumped)
262098 by: Per Jessen
262099 by: Per Jessen
262100 by: dev.lenss.nl
262102 by: Per Jessen
262103 by: Stut
262104 by: dev.lenss.nl
262105 by: dev.lenss.nl
262106 by: Per Jessen
262107 by: Per Jessen
262108 by: Per Jessen
262109 by: dev.lenss.nl
262110 by: Jay Blanchard
Re: my paging task with PHP does not work. It uses cookie.
262101 by: Arvids Godjuks
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
--- Begin Message ---
[EMAIL PROTECTED]
--- End Message ---
--- Begin Message ---
tedd wrote:
At 4:24 PM -0400 9/6/07, TG wrote:
The web server software has access to certain directories, but PHP
itself can
have access to things outside the main web folders.
That's good advice, but what do you do when safe_mode is ON?
My experience is that PHP can't access folders out of the web root.
Safe-mode shouldn't affect this particular problem, but open_basedir would.
--
Postgresql & php tutorials
http://www.designmagick.com/
--- End Message ---
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
On Fri, 14 Sep 2007 10:10:09 +0200, Per Jessen <[EMAIL PROTECTED]> 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.
--- End Message ---
--- Begin Message ---
[EMAIL PROTECTED] wrote:
> On Fri, 14 Sep 2007 10:10:09 +0200, Per Jessen <[EMAIL PROTECTED]>
> 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
--- End Message ---
--- Begin Message ---
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/
--- End Message ---
--- Begin Message ---
On Fri, 14 Sep 2007 11:09:36 +0200, Per Jessen <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
>> On Fri, 14 Sep 2007 10:10:09 +0200, Per Jessen <[EMAIL PROTECTED]>
>> 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.
--- End Message ---
--- Begin Message ---
On Fri, 14 Sep 2007 11:09:36 +0200, Per Jessen <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
>> On Fri, 14 Sep 2007 10:10:09 +0200, Per Jessen <[EMAIL PROTECTED]>
>> 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.
--- End Message ---
--- Begin Message ---
Stut wrote:
> 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.
Perhaps, but people do so anyway. Users of e.g. apache, linux, gcc,
mysql, <pick any filesystem>, iptables - they all expect near-perfect
behaviour (in the stable versions). I think at the very least we
should strive for near-perfect.
> 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.
As it happens I managed to cut the example down to just an empty XSLT
stylesheet. The PHP binary I'm using was built by openSUSE, I think
it's pretty bog standard.
> 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.
If extensions are really to be seen as completely separate from PHP
(even though they are shipped and included by default), PHP should
protect itself much better from them. Not even extensions should be
able to produce a segfault just like that. The example I sent doesn't
DO anything. The stylesheet is empty, the included file is empty.
In this particular case, the problem is not so much in the XSLT
extension - it is in fact caused by the previous virtual(). So back to
PHP. (and apache).
> 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.
I do think it's reasonable. It's a matter of setting the bar a little
higher - especially when people use your code in production, even in
commercial environments. When I see segfaults being caused by minor
typos, I know the bar has been set much too low.
> 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.
I've got other priorities and not enough time. Do a code-search on
google on my name and you'll see many other projects to which I have
actively contributed. E.g. hercules, etherboot and clamav.
/Per Jessen, Zürich
--- End Message ---
--- Begin Message ---
T.Lensselink wrote:
>>> 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.
Apologies, I had already cut the problem down to being caused by loading
an empty stylesheet. (which is also a syntax problem).
> 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.
Check that the virtual() call works. That's the _real_ problem.
/Per Jessen, Zürich
--- End Message ---
--- Begin Message ---
T.Lensselink wrote:
>>> 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.
Interesting - I know the problem is in the virtual() call, but it
doesn't manifest itself till the problem stylesheet is loaded.
/Per Jessen, Zürich
--- End Message ---
--- Begin Message ---
On Fri, 14 Sep 2007 12:00:19 +0200, Per Jessen <[EMAIL PROTECTED]> wrote:
> T.Lensselink wrote:
>
>>>> 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.
>
> Interesting - I know the problem is in the virtual() call, but it
> doesn't manifest itself till the problem stylesheet is loaded.
>
>
> /Per Jessen, Zürich
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
You are right. It segfaults only if the virtual() call comes before
creating the XSLTProcessor instance.
--- End Message ---
--- Begin Message ---
[snip]
You are right. It segfaults only if the virtual() call comes before
creating the XSLTProcessor instance.
[/snip]
I cannot replicate the problem on Linux.
--- End Message ---
--- Begin Message ---
Don't use SQL_CALC_FOUND ROWS on simple queries, when you have to run a
simple query on one or two (with join) tables with a simple WHERE. Especialy
if tables are big. I found out that single SELECT COUNT(id) FROM table is
far more faster when query has simple WHERE conditions. I use
SQL_CALC_FOUND_ROWS only with a rather complex queries - that
SQL_CALC_FOUND_ROWS doesn't affect query execution at all (well, it affects
ofcourse, but affect is so small, you can't see it).
--- End Message ---
