Edit report at https://bugs.php.net/bug.php?id=69864&edit=1
ID: 69864
Updated by: cmb@php.net
Reported by: james dot h dot cracknell at gmail dot com
Summary: Segfault in preg_replace_callback
Status: Verified
Type: Bug
Package: PCRE related
Operating System: Windows Server 2008 R2
PHP Version: 7.0.0alpha1
Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
Thanks for further investigation, Anatol, and the valuable hints.
Indeed, the valgrind issues are not (directly) related to the
patch. The following test script raises lots of these for current
master (w/o the patch):
<?php
for ($i = 0; $i < 10000; $i++) {
preg_replace('/foo'.$i.'bar/', 'baz',
'???foo'.$i.'bar???');
}
?>
All this depends on pcre.jit. If this (php.ini) configuration
option is disabled, valgrind reports no problems. Also James' test
script runs fine with the patch if pcre.jit is disabled.
It seems to me that the valgrind/pcre.jit issue is not directly
related to this ticket, and that it might be best to open a new
ticket for it. I think it would be preferable to solve that issue
before finally tackling this ticket.
Anyhow, disregard my comments regarding storing PCE vs. zval in
the HashTable. I had not read the code carefully enough.
Previous Comments:
------------------------------------------------------------------------
[2015-06-19 16:38:49] ab@php.net
Christoph, debugged a bit w/o your patch. Consider these two lines from the trace
pcre_study.c:1672
php_pcre.c:96
If you comment out the freeing of pce->extra, it'll pass but with memleaks. so that's
not your patch crashing at all. So suspect some double free with pce->extras is the issue now. I
think we should rethink the direction to go.
Thanks.
------------------------------------------------------------------------
[2015-06-19 15:26:56] ab@php.net
Ah, as from the patch, it should be
pcre_cache_entry *pce = (pcre_cache_entry *) Z_PTR_P(data);
but it probably won't fix the issue, just to mention.
Thanks.
------------------------------------------------------------------------
[2015-06-19 14:51:49] ab@php.net
i meant "using a crashy snippet without any patch" - so that's the plain situation
where you see all the errors ... :)
Thanks.
------------------------------------------------------------------------
[2015-06-19 14:50:35] ab@php.net
Hi Christoph,
nope, HashTable is unlikely to cause an issue. It's a very core API which is used everywhere,
so it's probably not causing this.
But if you're using the snippet from @james which is already know to cause crash, clear
there'll be such kinds of errors. So don't even need to mention that. And the cause of it,
as reported and also confirmed by yourself, is that the cache is freed without check which causes
accesses to the invalid memory. Except you've found out something new ;)
Thanks.
------------------------------------------------------------------------
[2015-06-19 13:40:36] cmb@php.net
Have you tried without the patch, Anatol? I get very similar
results before having applied the patch.
Nearly all of the warnings seem to be caused by
php_free_pcre_cache(). Storing non-zvals in a HashTable[1] might
not work reliably?
[1] <http://lxr.php.net/xref/PHP_TRUNK/ext/pcre/php_pcre.c#492>
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=69864
--
Edit this bug report at https://bugs.php.net/bug.php?id=69864&edit=1