Edit report at https://bugs.php.net/bug.php?id=75133&edit=1
ID: 75133
User updated by: php at richardneill dot org
Reported by: php at richardneill dot org
Summary: When preg_replace fails, please write to error_log
Status: Duplicate
Type: Feature/Change Request
Package: PCRE related
Operating System: Linux
PHP Version: 7.0.22
Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
Thanks for your comments. I'd like to respond as to why I think this is important.
1. PCRE errors happen in 2 situations.
(a) The user has written a regex that "explodes". Something like this:
http://www.regular-expressions.info/catastrophic.html
This is what I did; it's a very hard to find error (and worse, it manifests intermittently at
runtime dependent on the data). On the other hand, it is quite easy to hit this (it seems that the
combination of a negative assertion with two ungreedy '*' will do it on fairly small
data-sizes).
IMHO, this should be considered in the same category as a RE syntax error (which does get into
error_log).
(b) PHP itself has "failed" (this was once the case when the PCRE_backtrack_limit
defaulted to a tiny value, it can also happen with a segfault).
In both of these cases, an error in the logs is, I think, merited.
2. Please don't underestimate the sheer beauty of a helpful error message! It makes all the
difference between a tool that is delightful to work with, and one that causes hours of frustration.
Good error messages help the user, and make our job as (only-human) programmers fulfilling. Tools
that fail silently, especially on really rare edge-cases, are not so fun to use, even if the
programmer should have been responsible for carefully checking.
3. Finally, you say that with E_ALL, you wouldn't want to see this? I would suggest that any of
the PCRE failures are worthy of a log - if they occur, it means a subtle and nasty bug is lurking in
the code! This isn't like failing to check the return value of (say) file_get_contents(), which
can "reasonably" fail. A PCRE error is tantamount to a crash - and there's no way to
recover from it.
Thanks for your time and consideration.
Previous Comments:
------------------------------------------------------------------------
[2017-08-29 13:54:48] cmb@php.net
Duplicate of bug #51103.
------------------------------------------------------------------------
[2017-08-28 20:38:12] spam2 at rhsoft dot net
there is no reason to spit into the error log just because you don't properly check return
values where you can calk error_log() at your own
proper production servers have E_ALL enabled and if something spits into my logs or enforce using @
would lead to a bug report to fix that broken behavior
------------------------------------------------------------------------
[2017-08-28 18:33:45] php at richardneill dot org
Description:
------------
It's very rare that preg_replace() fails (i.e. returns null). But when it happens, it's
really unexpected, and therefore particularly hard to debug. All the normal tools show nothing
helpful.
Can I request that whenever preg_replace (and preg_replace_callback) return a null, that
preg_last_error() is printed to the error_log, at least at E_NOTICE?
Test script:
---------------
It may be helpful to give an example. This code generates a
PREG_JIT_STACKLIMIT_ERROR, with only ~ 5kB of data in $contents
$contents =
preg_replace_callback
('/^\s*\%LOOP_(\d+|(ITR)(\d))\s*\n((((?!%LOOP_ITR).)*\n)*)\s*\%END_LOOP\s*\n/mU',
'repeat_n_times', $contents);
Expected result:
----------------
It shouldn't be possible to write a 1-line regexp which hits resource-limits on one screenful
of text. But if we do, it would be really helpful if there were some error message in the log files.
Actual result:
--------------
PHP Notice: preg_replace experienced a PREG_JIT_STACKLIMIT_ERROR in (filename) on (line_number)
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=75133&edit=1