# #60038 SIGALRM cause segfault in php_error_cb - Thread: https://externals.io/message/55777 - Original archive: https://news-web.php.net/php.internals/55777 - Started by Laruence on 2011-10-11T09:30:40+00:00 - Messages: 13 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #55777 — Laruence — 2011-10-11T09:30:40+00:00 URL: https://externals.io/message/55777#55777 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/ --- ## #55783 — Ilia Alshanetsky — 2011-10-12T14:50:07+00:00 URL: https://externals.io/message/55777#55783 · In reply to: #55777 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/ --- ## #55784 — Stas Malyshev — 2011-10-12T14:59:26+00:00 URL: https://externals.io/message/55777#55784 · In reply to: #55783 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 --- ## #55785 — Xinchen Hui — 2011-10-13T00:16:39+00:00 URL: https://externals.io/message/55777#55785 · In reply to: #55784 Hi: If send signal enabled, no system will be called. Thkans Sent from my iPhone 在 2011-10-12，22:59，Stas Malyshev 写道： > Hi! > > > > […] > > 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 --- ## #55786 — Xinchen Hui — 2011-10-13T00:17:33+00:00 URL: https://externals.io/message/55777#55786 · In reply to: #55785 s,send,zend, Sent from my iPhone 在 2011-10-13，8:16，Xinchen Hui 写道： > Hi: > If send signal enabled, no system will be called. > > Thkans > > Sent from my iPhone > > 在 2011-10-12，22:59，Stas Malyshev 写道： > > > […] --- ## #55787 — Kalle Sommer Nielsen — 2011-10-13T07:33:17+00:00 URL: https://externals.io/message/55777#55787 · In reply to: #55785 Hi 2011/10/13 Xinchen Hui : > 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 --- ## #55791 — Xinchen Hui — 2011-10-13T15:50:33+00:00 URL: https://externals.io/message/55777#55791 · In reply to: #55787 2011/10/13 Kalle Sommer Nielsen : > Hi > > 2011/10/13 Xinchen Hui : > > […] > > 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 --- ## #55792 — Stas Malyshev — 2011-10-13T16:04:21+00:00 URL: https://externals.io/message/55777#55792 · In reply to: #55783 Hi! > > […] 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 --- ## #55830 — Sebastian Bergmann — 2011-10-17T00:54:55+00:00 URL: https://externals.io/message/55777#55830 · In reply to: #55784 > 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/ --- ## #55831 — Stas Malyshev — 2011-10-17T06:54:58+00:00 URL: https://externals.io/message/55777#55831 · In reply to: #55830 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 --- ## #55832 — Ferenc Kovacs — 2011-10-17T07:49:44+00:00 URL: https://externals.io/message/55777#55832 · In reply to: #55831 On Mon, Oct 17, 2011 at 8:54 AM, Stas Malyshev wrote: > Hi! > > > > > > […] > > 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 --- ## #55838 — Ilia Alshanetsky — 2011-10-17T12:49:56+00:00 URL: https://externals.io/message/55777#55838 · In reply to: #55832 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 wrote: > > > […] > 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 --- ## #55844 — Ferenc Kovacs — 2011-10-17T13:28:34+00:00 URL: https://externals.io/message/55777#55844 · In reply to: #55838 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. > > > > […] > to > > […] > isset($foo['bar'])?$foo['bar']**:null. > > […] > to > > […] > value > > […] > -- Ferenc Kovács @Tyr43l - http://tyrael.hu