#60038 SIGALRM cause segfault in php_error_cb

13 years ago by Laruence — view source

unread

Hi:
I filed a bug about SIGALRM(or SIGPROF) has chance to cause
segfault in php_error_cb. https://bugs.php.net/bug.php?id=60038

do you think this is worth fixing (in 5.4 trunk)? (as zend_signal

was introduced, and this fix will cost litte perf).

thanks

--
Laruence Xinchen Hui
http://www.laruence.com/

13 years ago by Ilia Alshanetsky — view source

unread

Seems like a fine solution, performance loss would occur only when
error happens...

Hi:
I filed a bug about SIGALRM(or SIGPROF) has chance to cause
segfault in php_error_cb. https://bugs.php.net/bug.php?id=60038

do you think this is worth fixing (in 5.4 trunk)? (as zend_signal
was introduced, and this fix will cost litte perf).

thanks

--
Laruence Xinchen Hui
http://www.laruence.com/

13 years ago by Stas Malyshev — view source

unread

Hi!

Seems like a fine solution, performance loss would occur only when
error happens...

Note that on 99% of real PHP code, dozens of "errors" may happen due to
multitude of notices and E_STRICTs that we have now and we have no means
to disable until the very last moment before printing them. If each of
them would cost two system calls, we may have a serious performance problem.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

13 years ago by Xinchen Hui — view source

unread

Hi:
If send signal enabled, no system will be called.

Thkans

Sent from my iPhone

在 2011-10-12，22:59，Stas Malyshev smalyshev@sugarcrm.com 写道：

Hi!

Seems like a fine solution, performance loss would occur only when
error happens...

Note that on 99% of real PHP code, dozens of "errors" may happen due to multitude of notices and E_STRICTs that we have now and we have no means to disable until the very last moment before printing them. If each of them would cost two system calls, we may have a serious performance problem.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

13 years ago by Xinchen Hui — view source

unread

s,send,zend,

Sent from my iPhone

在 2011-10-13，8:16，Xinchen Hui laruence@gmail.com 写道：

Hi:
If send signal enabled, no system will be called.

Thkans

Sent from my iPhone

在 2011-10-12，22:59，Stas Malyshev smalyshev@sugarcrm.com 写道：

Hi!

Seems like a fine solution, performance loss would occur only when
error happens...

Note that on 99% of real PHP code, dozens of "errors" may happen due to multitude of notices and E_STRICTs that we have now and we have no means to disable until the very last moment before printing them. If each of them would cost two system calls, we may have a serious performance problem.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

13 years ago by Kalle Sommer Nielsen — view source

unread

2011/10/13 Xinchen Hui laruence@gmail.com:

Hi:
If send signal enabled, no system will be called.

Thkans

What about systems without Zend Signal Handling, like Windows?

--
regards,

Kalle Sommer Nielsen
kalle@php.net

13 years ago by Xinchen Hui — view source

unread

2011/10/13 Kalle Sommer Nielsen kalle@php.net:

Hi

2011/10/13 Xinchen Hui laruence@gmail.com:

Hi:
If send signal enabled, no system will be called.

Thkans

What about systems without Zend Signal Handling, like Windows?
hmm, I have updated the patch, the fix only take affect when
ZEND_SIGNALS defined. :)

thanks

--
regards,

Kalle Sommer Nielsen
kalle@php.net

--
惠新宸 laruence
Senior PHP Engineer
http://www.laruence.com

13 years ago by Sebastian Bergmann — view source

unread

Note that on 99% of real PHP code, dozens of "errors" may happen due to
multitude of notices and E_STRICTs that we have now and we have no means
to disable until the very last moment before printing them.

Such a performance regression sounds like an appropriate "punishment" to
me for deploying bad code ;-)

--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

13 years ago by Stas Malyshev — view source

unread

Hi!

Such a performance regression sounds like an appropriate "punishment" to
me for deploying bad code ;-)

By bad code you mean not obsessively checking for stuff that is of no
importance to them as programmers and is only required because language
implementers decided to go B&D on their users? ;)

I personally hate to see all these isset($foo['bar'])?$foo['bar']:null.
I think it's bad we make people do that.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

13 years ago by Ferenc Kovacs — view source

unread

On Mon, Oct 17, 2011 at 8:54 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:

Hi!

Such a performance regression sounds like an appropriate "punishment" to
me for deploying bad code ;-)

By bad code you mean not obsessively checking for stuff that is of no
importance to them as programmers and is only required because language
implementers decided to go B&D on their users? ;)

I personally hate to see all these isset($foo['bar'])?$foo['bar']**:null.
I think it's bad we make people do that.

and there are cases when you can't avoid triggering errors (like trying to
delete delete a while which can be deleted concurrently) so your only
option is to suppress them and handle the result based on the return value
of the statement.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

13 years ago by Ilia Alshanetsky — view source

unread

Unless you are deleting thousands of files in a tight loop, the
overhead involved won't make any difference for your application.

In general your application is throwing many errors, even "benign"
E_STRICT or E_NOTICE you are already incurring a performance hit.

On Mon, Oct 17, 2011 at 8:54 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:

Hi!

Such a performance regression sounds like an appropriate "punishment" to
me for deploying bad code ;-)

By bad code you mean not obsessively checking for stuff that is of no
importance to them as programmers and is only required because language
implementers decided to go B&D on their users? ;)

I personally hate to see all these isset($foo['bar'])?$foo['bar']**:null.
I think it's bad we make people do that.

and there are cases when you can't avoid triggering errors (like trying to
delete delete a while which can be deleted concurrently) so your only
option is to suppress them and handle the result based on the return value
of the statement.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

13 years ago by Ferenc Kovacs — view source

unread

I know, I've just replied with an example to the "Such a performance
regression sounds like an appropriate "punishment" to me for deploying bad
code ;-)" statement.

btw:
http://www.tyrael.hu/2011/06/26/performance-of-error-handling-in-php/
http://www.tyrael.hu/2011/10/09/error-suppression-improvements-with-php-5-4/

Unless you are deleting thousands of files in a tight loop, the
overhead involved won't make any difference for your application.

In general your application is throwing many errors, even "benign"
E_STRICT or E_NOTICE you are already incurring a performance hit.

On Mon, Oct 17, 2011 at 8:54 AM, Stas Malyshev <smalyshev@sugarcrm.com
wrote:

Hi!

Such a performance regression sounds like an appropriate "punishment"
to
me for deploying bad code ;-)

By bad code you mean not obsessively checking for stuff that is of no
importance to them as programmers and is only required because language
implementers decided to go B&D on their users? ;)

I personally hate to see all these
isset($foo['bar'])?$foo['bar']**:null.
I think it's bad we make people do that.

and there are cases when you can't avoid triggering errors (like trying
to
delete delete a while which can be deleted concurrently) so your only
option is to suppress them and handle the result based on the return
value
of the statement.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

13 years ago by Stas Malyshev — view source

unread

Hi!

do you think this is worth fixing (in 5.4 trunk)? (as zend_signal
was introduced, and this fix will cost litte perf).

OK, if it doesn't cost performance then I guess it's fine to apply it.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

#60038 SIGALRM cause segfault in php_error_cb

Note that on 99% of real PHP code, dozens of "errors" may happen due to multitude of notices and E_STRICTs that we have now and we have no means to disable until the very last moment before printing them. If each of them would cost two system calls, we may have a serious performance problem.

Note that on 99% of real PHP code, dozens of "errors" may happen due to multitude of notices and E_STRICTs that we have now and we have no means to disable until the very last moment before printing them. If each of them would cost two system calls, we may have a serious performance problem.

Note that on 99% of real PHP code, dozens of "errors" may happen due to multitude of notices and E_STRICTs that we have now and we have no means to disable until the very last moment before printing them. If each of them would cost two system calls, we may have a serious performance problem.

I personally hate to see all these isset($foo['bar'])?$foo['bar']:null. I think it's bad we make people do that.

OK, if it doesn't cost performance then I guess it's fine to apply it.

Note that on 99% of real PHP code, dozens of "errors" may happen due to
multitude of notices and E_STRICTs that we have now and we have no means
to disable until the very last moment before printing them. If each of
them would cost two system calls, we may have a serious performance problem.

I personally hate to see all these isset($foo['bar'])?$foo['bar']:null.
I think it's bad we make people do that.