Re: Crashes in lex_scan at Zend/zend_language_scanner.c / BUG #52752
| From: | Patrick Schaaf | Date: | Fri, 21 Dec 2012 09:24:11 +0000 |
| Subject: | Re: Crashes in lex_scan at Zend/zend_language_scanner.c / BUG #52752 | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-64405@lists.php.net to get a copy of this message | ||
On Friday 21 December 2012 10:41:59 Jani Ollikainen wrote:
> > So, my conclusion would be that it is the code snippet above, and not any
> > part of PHP or the kernel, that is at fault.
>
> Oh? Did I understand you correctly? If you can code PHP that crashes
> PHP, it's that codes fault not PHP's fault? I've always thought PHP
> to be high level programming language where PHP handles things for
> you and you can't code anything that crashes it like that with
> bus error?
I understand your sentiment.
To follow up the sentiment in code, there would be two options:
1) capture SIGBUS (and SIGSEGV probably, depending on platform), and in the
signal handler, to lots of funny dances to guess from the stack what kind of
error message would be helpful to the end user or end developer.
2) remove any attempt to use mmap to speed up reading, generally, or as an ini
option.
I would personally expect mmap-reading not to make a huge difference in
performance anyway, as the short segment double buffering that it avoids, will
probably be swamped by any kind of parsing of the content anyway. But probably
when people went to the lengths of implementing mmap based reading in the PHP
core, they had some good reasons to do so...
> I think that it should at least gracefully exit, log error, what caused
> what and where. Better option would be that it just works.
It CANNOT just work. It wouldn't work reliably without any use of mmap,
either. Concurrently modifying and reading one and the same file, will always
run into consistency problems, and doing that is CERTAINLY the fault of the
code that does it.
best regards
Patrick