ID: 45546
Comment by: keltia at gmail dot com
Reported By: kaiser at macbureau dot de
Status: No Feedback
Bug Type: PCRE related
Operating System: FreeBSD 7
PHP Version: 5.2.6
New Comment:
I have a similar problem after upgrading to PHP 5.2.8/PCRE 7.8 on a
FreeBSD 7.1/amd64. I'm trying to upgrade Gallery2 to 2.3 and the
installer fails with that error.
[Tue Jan 27 12:28:12 2009] [notice] child pid 92633 exit signal Illegal
instruction (4)
Previous Comments:
------------------------------------------------------------------------
[2009-01-27 02:16:43] jdw at wheelhouse dot org
We are also having this problem on FreeBSD 7 with Apache 1.3. The
stack trace is the same:
#0 0x286dcbc7 in match () from /usr/local/lib/libpcre.so.0
#1 0x286e3aba in match () from /usr/local/lib/libpcre.so.0
#2 0x286e3aba in match () from /usr/local/lib/libpcre.so.0
#3 0x286e469e in match () from /usr/local/lib/libpcre.so.0
#4 0x286dd629 in match () from /usr/local/lib/libpcre.so.0
#5 0x286e76c4 in pcre_exec () from /usr/local/lib/libpcre.so.0
#6 0x284b72fe in php_pcre_match_impl ()
from /nfsn/apps/apache/libexec/libphp5.so
#7 0x284b7cac in php_do_pcre_match ()
from /nfsn/apps/apache/libexec/libphp5.so
#8 0x285db1a8 in zend_do_fcall_common_helper_SPEC ()
from /nfsn/apps/apache/libexec/libphp5.so
#9 0x285cca7f in execute () from /nfsn/apps/apache/libexec/libphp5.so
#10 0x28b2f0c2 in _su3jdmx ()
from /nfsn/apps/php5/lib/php/extensions/no-debug-non-zts-
20060613/ioncube_loader_fre_5.2.so
#11 0x2af863d8 in ?? ()
#12 0x29e80750 in ?? ()
#13 0x29e7f75c in ?? ()
#14 0x285dac0e in zend_do_fcall_common_helper_SPEC ()
from /nfsn/apps/apache/libexec/libphp5.so
(This version was built with the FreeBSD PCRE instead of the builtin
in case that helped; it didn't.)
In one case, a customer has to set pcre.backtrack_limit and
pcre.recursion_limit to 10 to get a Wordpress RSS feed to load.
Are those considered "sane" values?
Or is this getting ignored due to the incorrect "No Feedback" status?
------------------------------------------------------------------------
[2009-01-14 13:00:22] jdc at parodius dot com
I've built PHP 5.2.8 with debugging enabled, and ran the following
script under PHP via the CLI, under gdb:
<?php
$str = str_repeat('a', 1244);
$utf8 =
(preg_match("/^([\x09\x0A\x0D\x20-\x7E]|[\xC2-\xDF][\x80-\xBF]|\xE0[\xA0-\xBF][\x80-\xBF]|[\xE1-\xEC\xEE\xEF][\x80-\xBF]{2}|
\xED[\x80-\x9F][\x80-\xBF]|\xF0[\x90-\xBF][\x80-\xBF]{2}|[\xF1-\xF3][\x80-\xBF]{3}|\xF4[\x80-\x8F][\x80-\xBF]{2})*$/",
$str)) ? "yes
" : "no";
echo $utf8;
?>
It's important to note that if I change the str_repeat() length from
1244 to 1243, the segfault doesn't happen. The system limits:
Resource limits (current):
cputime infinity secs
filesize infinity kB
datasize 786432 kB
stacksize 131072 kB
coredumpsize infinity kB
memoryuse infinity kB
memorylocked infinity kB
maxprocesses 5547
openfiles 11095
sbsize infinity bytes
vmemoryuse infinity kB
Anyway, the results of the gdb backtrace are here (~790KB file):
http://www.malkavian.com/~jdc/php.bug45546.backtrace.txt
Hope this helps.
------------------------------------------------------------------------
[2009-01-14 12:27:59] jdc at parodius dot com
This bug still exists in PHP 5.2.8, which uses its own bundled version
of pcre. FreeBSD 7.1-STABLE is being used here.
I have a customer who is experiencing this problem on a near-daily
basis (logs showing httpd SIGILL regularly).
I can induce a signal 11 from the shell (using PHP CLI) executing the
code provided by "hempalex at gmail dot com" as well as the code
provided by "kaiser at macbureau dot de". The comment from "ale at
FreeBSD.org" also applies -- the value given to str_repeat() does in
fact play a role.
But when run from within Apache (2.2.11 using mod_php), signal 4
(illegal instruction) happens. I'm not sure why from within Apache it's
SIGILL but from the command-line it's SIGSEGV.
Increasing pcre.backtrack_limit and pcre.recursion_limit does not help.
Decreasing them also does not help.
I'd like to urge the PHP folks to take this problem seriously. There
are many of us using FreeBSD who would be more than happy to give you an
account on a development/test system for you to work out the source of
this problem.
------------------------------------------------------------------------
[2008-09-26 16:17:20] nlop...@php.net
again I cannot reproduce this problem. Try to adjust
pcre.backtrack_limit and pcre.recursion_limit to some sane values.
------------------------------------------------------------------------
[2008-09-26 09:17:06] ale at FreeBSD dot org
The feedback was provided.
In any case the above script works if the string length is <= 2243 and
stops working if > 2243 'a' chars.
------------------------------------------------------------------------
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
http://bugs.php.net/45546
--
Edit this bug report at http://bugs.php.net/?id=45546&edit=1
