php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #58351 APC segfault (out of bounds memory access)
Submitted: 2008-09-22 14:26 UTC Modified: 2016-08-31 15:04 UTC
Votes:1
Avg. Score:3.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: rkahler at digitalriver dot com Assigned: cmb (profile)
Status: Wont fix Package: APC (PECL)
PHP Version: 5.2.6 OS: RedHat Workstation 3
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:
23 - 4 = ?
Subscribe to this entry?

 
 [2008-09-22 14:26 UTC] rkahler at digitalriver dot com
Description:
------------
We recently upgraded several servers to PHP 5.2.6, and the one server we current have configured with APC is running into segfaults (quite frequently). Here's the configuration for that server:

Apache 1.3.41
PHP 5.2.6 (w/ following extensions)
* OCI8 1.2.3
* Suhosin 0.9.27
* ZIP 1.8.10
* xdebug 2.0.0

Here's our PHP configure line:
./configure --prefix=/opt/php.${DATE} --with-apxs=/opt/apache/bin/apxs --with-openssl --with-mysql --with-curl=../curl-7.12.2 --enable-track-vars --enable-sockets --enable-sysvshm --enable-sysvsem --enable-posix --with-pear --enable-sigchild --enable-php-streams --with-gettext --enable-ftp --with-xml --with-gd --with-zlib --with-dom --with-mm --with-mcrypt --enable-mbstring --enable-soap

The only relevant changes we've made to our php.ini are configuration parameters for the various extensions. These parameters worked just fine for our previous installations. We just upgraded from PHP 5.1.6 and APC 3.0.16, as well as upgrading from HardenedPHP 0.4.15 to Suhosin 0.9.27 (extension only, not using the patch). Everything else is unchanged.

It might (or might not) also be worth noting that we're using the same configuration as above, minus APC and xdebug, on two other servers that are not experiencing this issue at all.


Reproduce code:
---------------
We're unable to isolate a single script that is triggering this issue. It seems to be happening randomly.

Actual result:
--------------
#0  0x0035a7d4 in __pthread_alt_unlock () from /lib/i686/libpthread.so.0
#1  0x0035746c in pthread_mutex_unlock () from /lib/i686/libpthread.so.0
#2  0x001fd3af in pthread_mutex_unlock () from /lib/i686/libc.so.6
#3  0x007d7f9d in apc_pthreadmutex_unlock (lock=0x657e1d) at /usr/local/src/bh-web/APC-3.0.19/apc_pthreadmutex.c:82
#4  0x007d1a51 in apc_cache_find_slot (cache=0x9458ea8, key=
      {data = {file = {device = 18, inode = 0}, user = {identifier = 0x12 <Address 0x12 out of bounds>, identifier_len = 0}, fpfile = {fullpath = 0x12 <Address 0x12 out of bounds>, fullpath_len = 0}}, mtime = 1222105181, type = 1 '\001'}, t=1222105673) at /usr/local/src/bh-web/APC-3.0.19/apc_cache.c:560
#5  0x007d1b07 in apc_cache_find (cache=0x657e1d, key=
      {data = {file = {device = 18, inode = 6651421}, user = {identifier = 0x12 <Address 0x12 out of bounds>, identifier_len = 0}, fpfile = {fullpath = 0x12 <Address 0x12 out of bounds>, fullpath_len = 0}}, mtime = 1222105181, type = 1 '\001'}, t=6651421) at /usr/local/src/bh-web/APC-3.0.19/apc_cache.c:568
#6  0x007d69ba in my_compile_file (h=0xbfff9270, type=8) at /usr/local/src/bh-web/APC-3.0.19/apc_main.c:343
#7  0x0067b426 in xdebug_compile_file (file_handle=0xbfff9270, type=8) at /usr/local/src/bh-web/xdebug-2.0.0/xdebug.c:2332
#8  0x0144a492 in zend_execute_scripts () from /usr/local/www/libexec/libphp5.so
#9  0x01403313 in php_execute_script () from /usr/local/www/libexec/libphp5.so
#10 0x014aea28 in apache_php_module_main () from /usr/local/www/libexec/libphp5.so
#11 0x014af7bb in send_php () from /usr/local/www/libexec/libphp5.so
#12 0x014af80d in send_parsed_php () from /usr/local/www/libexec/libphp5.so
#13 0x08055137 in ap_invoke_handler ()
#14 0x0806c807 in process_request_internal ()
#15 0x0806c864 in ap_process_request ()
#16 0x080629cf in child_main ()
#17 0x08062ce1 in make_child ()
#18 0x08063115 in perform_idle_server_maintenance ()
#19 0x080637bf in standalone_main ()
#20 0x08063e48 in main ()

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-09-22 14:37 UTC] gopalv82 at yahoo dot com
Something looks really odd here

0x007d7f9d in apc_pthreadmutex_unlock (lock=0x657e1d)
0x007d1a51 in apc_cache_find_slot (cache=0x9458ea8,
0x007d1b07 in apc_cache_find (cache=0x657e1d, 

if you still have this core lying around, can you tell me what the following return in gdb

(gdb) p apc_cache
(gdb) p apc_cache->header
(gdb) p apc_cache->header->lock

And somehow the key itself changed

      {data = {file = {device = 18, inode = 6651421},

to 
      {data = {file = {device = 18, inode = 0},
 [2008-09-22 14:40 UTC] rkahler at digitalriver dot com
Thanks for such a quick response. Here's the gdb output you requested.

(gdb) p apc_cache
$1 = (apc_cache_t *) 0x843be48
(gdb) p apc_cache->header
$2 = (cache_header_t *) 0xab3a6048
(gdb) p apc_cache->header->lock
$3 = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = -1073786452, __spinlock = 0}}
 [2016-08-31 15:04 UTC] cmb@php.net
-Status: Open +Status: Wont fix -Assigned To: +Assigned To: cmb
 [2016-08-31 15:04 UTC] cmb@php.net
According to <https://bugs.php.net/69618>, APC support has been
discontinued in favor of OPcache, APCu, the session upload
progress API and WinCache. Therefore this issue won't get fixed.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 19 20:01:29 2024 UTC