php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #72147 Segmentation fault in /lib/x86_64-linux-gnu/libpcre.so.3 called by php_free_pcr
Submitted: 2016-05-03 21:38 UTC Modified: 2016-05-22 04:22 UTC
Votes:4
Avg. Score:4.5 ± 0.9
Reproduced:4 of 4 (100.0%)
Same Version:4 (100.0%)
Same OS:2 (50.0%)
From: tom60 at op dot pl Assigned:
Status: No Feedback Package: Reproducible crash
PHP Version: 7.0.6 OS: Debian Jessie 64 bit
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
MUST BE VALID
Solve the problem:
8 + 43 = ?
Subscribe to this entry?

 
 [2016-05-03 21:38 UTC] tom60 at op dot pl
Description:
------------
PHP 7.0.6 compiled with libpcre3:amd64 2:8.35-3.3+deb8u4 on Debian Jessie crashes from time to time. For us it occurs mostly when we deploy new PHP code to a webserver. During the deploy we call opcache_reset(). 

PHP 5.6.21 on the same server with the same libraries is rock-solid. That's why I think it might be the issue with the way PHP 7 uses the PCRE library.

I've attached a backtrace from GDB. Please let me know if I should supply any more details.

Actual result:
--------------
Reading symbols from /opt/apache2/sbin/apache2...done.
[New LWP 22823]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/opt/apache2/sbin/apache2 -k start'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f62bd412ae5 in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
(gdb) bt
#0  0x00007f62bd412ae5 in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
#1  0x00007f62bd438508 in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
#2  0x00007f62bd43a13c in pcre_free_study () from /lib/x86_64-linux-gnu/libpcre.so.3
#3  0x00007f62bb2a4863 in php_free_pcre_cache (data=<optimized out>) at /src/php-7.0.6/ext/pcre/php_pcre.c:113
#4  0x00007f62bb5e6534 in zend_hash_destroy (ht=0x7f62bbf3b940 <pcre_globals>) at /src/php-7.0.6/Zend/zend_hash.c:1284
#5  0x00007f62bb2a47e9 in zm_globals_dtor_pcre (pcre_globals=<optimized out>) at /src/php-7.0.6/ext/pcre/php_pcre.c:136
#6  0x00007f62bb5dc579 in module_destructor (module=module@entry=0x7f62bf28c3e0) at /src/php-7.0.6/Zend/zend_API.c:2516
#7  0x00007f62bb5d501c in module_destructor_zval (zv=<optimized out>) at /src/php-7.0.6/Zend/zend.c:615
#8  0x00007f62bb5e7049 in _zend_hash_del_el_ex (prev=<optimized out>, p=<optimized out>, idx=<optimized out>, ht=<optimized out>)
    at /src/php-7.0.6/Zend/zend_hash.c:1026
#9  _zend_hash_del_el (p=0x7f62bf2a4780, idx=4, ht=0x7f62bbf42840 <module_registry>) at /src/php-7.0.6/Zend/zend_hash.c:1050
#10 zend_hash_graceful_reverse_destroy (ht=ht@entry=0x7f62bbf42840 <module_registry>) at /src/php-7.0.6/Zend/zend_hash.c:1502
#11 0x00007f62bb5daa3c in zend_destroy_modules () at /src/php-7.0.6/Zend/zend_API.c:1984
#12 0x00007f62bb5d5fd5 in zend_shutdown () at /src/php-7.0.6/Zend/zend.c:840
#13 0x00007f62bb57a35b in php_module_shutdown () at /src/php-7.0.6/main/main.c:2362
#14 0x00007f62bb57a419 in php_module_shutdown_wrapper (sapi_globals=<optimized out>) at /src/php-7.0.6/main/main.c:2330
#15 0x00007f62bb667861 in php_apache_child_shutdown (tmp=<optimized out>) at /src/php-7.0.6/sapi/apache2handler/sapi_apache2.c:399
#16 0x00007f62bcb6bfae in run_cleanups (cref=<optimized out>) at memory/unix/apr_pools.c:2352
#17 apr_pool_destroy (pool=0x7f62bf3df8d8) at memory/unix/apr_pools.c:814
#18 0x00007f62bdfa37be in clean_child_exit (code=0) at prefork.c:227
#19 0x00007f62bdfa3ca8 in child_main (child_num_arg=-1110591680, child_bucket=1189753504) at prefork.c:744
#20 0x00007f62bdfa4050 in make_child (s=0x7f62bf1349a8, slot=45, bucket=0) at prefork.c:824
#21 0x00007f62bdfa4ea5 in perform_idle_server_maintenance (p=<optimized out>) at prefork.c:932
#22 prefork_run (_pconf=0x7f62bdcdb740, plog=0x7ffc46ea3390, s=0x7ffc46ea3350) at prefork.c:1128
#23 0x00007f62bdf2489e in ap_run_mpm (pconf=0x7f62bf101138, plog=0x7f62bf13a818, s=0x7f62bf1349a8) at mpm_common.c:94
#24 0x00007f62bdf1de15 in main (argc=3, argv=0x7ffc46ea3628) at main.c:778

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-05-03 21:54 UTC] tom60 at op dot pl
As for PCRE settings, we use the defaults:

pcre.backtrack_limit	1000000
pcre.jit	1
pcre.recursion_limit	100000

I noticed that "pcre.jit" was introduced in PHP 7, I will try to disable it and see if the situation improves.
 [2016-05-05 12:49 UTC] tom60 at op dot pl
Looks like setting pcre.jit=0 eliminates the segmentation faults. 

It's worth looking into this issue, as the crash occurs on PHP 7.0.6 with the default settings (pcre.jit=1) on the most recent version of Debian Jessie with libpcre3:amd64 2:8.35-3.3+deb8u4.
 [2016-05-09 19:29 UTC] zulrang at gmail dot com
Experiencing the same issue on SPARCv9/Solaris 11 using pcre 8.38

$ pcre-config --version
8.38

./configure --disable-all --disable-cgi --disable-phpdbg --disable-opcache --disable-libgcc

make test fails with a Bus Error

Can also reproduce:

Failing script: $ sapi/cli/php -r 'preg_match("/a/", "abc");'
Result: Bus Error

Disabling pcre.jit fixes the issue.
 [2016-05-10 13:07 UTC] ckiendl at backfactory dot de
We seem to have the same issue using
PHP 7.0.6-1~dotdeb+8.1

Server version: Apache/2.4.10 (Debian)
Server built:   Nov 28 2015 14:05:48

Linux [hostname redacted] 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-1 (2016-03-06) x86_64 GNU/Linux

libpcre3 version: 2:8.35-3.3+deb8u4

Reproducible errors in the vein of
*** Error in `apache2': munmap_chunk(): invalid pointer: 0x00007f...
with the default settings, immediately working after I changed the configuration to pcre.jit=0.
 [2016-05-12 09:58 UTC] ab@php.net
-Status: Open +Status: Feedback
 [2016-05-12 09:58 UTC] ab@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

Unfortunately preg_match("/a/", "abc") doesn't repro any crash, but we need a reproducer.

Thanks
 [2016-05-22 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 19 18:01:28 2024 UTC