Bug #67687 [Com]: Crash or zend_mm_heap_corrupted error in opcache with OwnCloud 7 update

Edit report at https://bugs.php.net/bug.php?id=67687&edit=1 ID: 67687 Comment by: software-php at interfasys dot ch Reported by: adamw at happyassassin dot net Summary: Crash or zend_mm_heap_corrupted error in opcache with OwnCloud 7 update Status: Open Type: Bug Package: opcache Operating System: Fedora 20 PHP Version: 5.5.15 Block user comment: N Private report: N New Comment: Still a problem on PHP 5.5.22 Previous Comments: ------------------------------------------------------------------------ [2014-07-27 13:25:46] patricknn at gmail dot com I have the same issue, the crash is random and happen in some pages with no reason PHP 5.5.11 ------------------------------------------------------------------------ [2014-07-26 06:44:32] adamw at happyassassin dot net Remi Collet seems to have spotted the code in OwnCloud that triggers the problem: it's the function clearOpcodeCache() in lib/private/util.php , https://github.com/owncloud/core/blob/v7.0.0/lib/private/util.php#L1351 . If I comment out the // Opcache (PHP >= 5.5) lines there, the crash stops happening. Somehow, OC manually resetting the opcache at that particular point is causing it to crash. That function is called only by lib/private/config.php , when it's changing config file values. So I believe this is triggered when lib/base.php 's checkUpgrade() function does this, on line 290: $oldTheme = OC_Config::getValue('theme'); OC_Config::setValue('theme', ''); that calls setValue() in config.php , and setValue() calls writeData(), and writeData() calls clearOpcodeCache() , and boom. ------------------------------------------------------------------------ [2014-07-26 01:11:29] adamw at happyassassin dot net Sorry, I gave the wrong link to the affected OwnCloud code. That's the code that actually *runs* the database update. I have actually seen the crash occur in the middle of a database upgrade (which is obviously bad), but the consistent reproducer I have is when just looking at the page which notifies you an upgrade is needed - it reads "ownCloud will be updated to version 7.0.0. Please make sure that the database, the config folder and the data folder have been backed up before proceeding.", and has a "Start update" button. That code is in https://github.com/owncloud/core/blob/v7.0.0/lib/base.php , particularly see the checkUpgrade() function on line 286. ------------------------------------------------------------------------ [2014-07-26 00:53:35] adamw at happyassassin dot net Description: ------------ I've been hitting a fairly reproducible crash in the PHP 5.5 Zend opcache, when accessing the OwnCloud 7 update page (which is displayed the first time you access an OwnCloud installation after upgrading OwnCloud - it updates the database for the new OC release). I'll include a backtrace of the crash (the backtrace is from my 'live' OC deployment and was with PHP 5.5.14, but I've verified that a clean install with PHP 5.5.15 also hits the crash). The affected code in OwnCloud is https://github.com/owncloud/core/blob/stable7/core/ajax/update.php (though you may need some familiarity with the OC codebase to work out where all the stuff it calls comes from). I have the bug reproduced with a fresh deployment of Fedora 20 and OwnCloud on a disposable test system, and I can provide remote shell access to that system for any dev interested in trying to debug this issue. I have also reported this issue to OwnCloud at https://github.com/owncloud/core/issues/9885 , where there are some more specific details about exactly how to reproduce it (basically, install Fedora 20, install a web server environment including the PHP opcache, do a minimal initial deployment of OwnCloud 6, then update it to OwnCloud 7, access the OC deployment - which will direct you to the update page - and then refresh the page a few times). Remi Collet (Fedora PHP maintainer) suggested to me that it probably constitutes a bug in PHP any time vaguely sane PHP code causes a crash in the opcache like this, so I thought reporting it to PHP would also make sense. Actual result: -------------- Thread 1 (Thread 0x7ffb746da880 (LWP 27950)): #0 zend_mm_add_to_free_list (heap=<optimized out>, mm_block=0x7ffb769df1b0) at /usr/src/debug/php-5.5.14/Zend/zend_alloc.c:752 prev = 0x7ffb76a0c3b800 m = 9223372036854775808 p = 0x7ffb76a06cdf size = 680 index = <optimized out> #1 0x00007ffb65db6269 in _zend_mm_free_int (heap=0x7ffb765a7690, p=0x7ffb769df2e0) at /usr/src/debug/php-5.5.14/Zend/zend_alloc.c:2118 mm_block = 0x7ffb769df1b0 next_block = 0x7ffb769df320 size = 680 #2 0x00007ffb65ded3c8 in zend_hash_destroy (ht=0x7ffb661d50f0 <compiler_globals+272>) at /usr/src/debug/php-5.5.14/Zend/zend_hash.c:560 p = 0x7ffb76b7a840 q = 0x7ffb769df468 #3 0x00007ffb65dbac08 in shutdown_compiler () at /usr/src/debug/php-5.5.14/Zend/zend_compile.c:243 No locals. #4 0x00007ffb65ddecdd in zend_deactivate () at /usr/src/debug/php-5.5.14/Zend/zend.c:938 __orig_bailout = 0x0 __bailout = {{__jmpbuf = {140717726714592, 1220331504840024189, 140718002600480, 140717969548992, 0, 140718002558800, 1217778156862513277, 1220328752599343229}, __mask_was_saved = 0, __saved_mask = {__val = {0, 9, 0, 0, 0, 140737186205984, 140717726712640, 140717726714184, 140717969548992, 0, 140717722556736, 140737186205984, 140717726712640, 140718002600480, 140717722232828, 0}}}} #5 0x00007ffb65d7c575 in php_request_shutdown (dummy=dummy@entry=0x0) at /usr/src/debug/php-5.5.14/main/main.c:1808 report_memleaks = 1 '\001' #6 0x00007ffb65e93eaf in php_apache_request_dtor (r=<optimized out>) at /usr/src/debug/php-5.5.14/sapi/apache2handler/sapi_apache2.c:507 No locals. #7 php_handler (r=<optimized out>) at /usr/src/debug/php-5.5.14/sapi/apache2handler/sapi_apache2.c:679 ctx = 0x7ffb76906168 conf = <optimized out> brigade = 0x7ffb768f25b8 bucket = <optimized out> rv = <optimized out> parent_req = 0x0 #8 0x00007ffb7472f290 in ap_run_handler (r=0x7ffb768efa20) at config.c:169 pHook = 0x7ffb7655c850 n = 12 rv = -1597786112 #9 0x00007ffb7472f7d9 in ap_invoke_handler (r=r@entry=0x7ffb768efa20) at config.c:439 handler = <optimized out> p = <optimized out> result = <optimized out> old_handler = 0x7ffb7654a660 "application/x-httpd-php" ignore = <optimized out> #10 0x00007ffb7474436a in ap_process_async_request (r=r@entry=0x7ffb768efa20) at http_request.c:317 access_status = 0 #11 0x00007ffb74744644 in ap_process_request (r=r@entry=0x7ffb768efa20) at http_request.c:363 bb = <optimized out> b = <optimized out> c = 0x7ffb768e5750 rv = <optimized out> #12 0x00007ffb74741002 in ap_process_http_sync_connection (c=0x7ffb768e5750) at http_core.c:190 r = 0x7ffb768efa20 cs = 0x0 csd = 0x0 mpm_state = 0 #13 ap_process_http_connection (c=0x7ffb768e5750) at http_core.c:231 No locals. #14 0x00007ffb74738e40 in ap_run_process_connection (c=0x7ffb768e5750) at connection.c:41 pHook = 0x7ffb7655d018 n = 2 rv = -1597786112 #15 0x00007ffb74739228 in ap_process_connection (c=c@entry=0x7ffb768e5750, csd=<optimized out>) at connection.c:202 rc = <optimized out> #16 0x00007ffb69e737ef in child_main (child_num_arg=child_num_arg@entry=5) at prefork.c:704 current_conn = 0x7ffb768e5750 csd = 0x7ffb768e5560 thd = 0x7ffb768e3550 osthd = 140717966862464 ptrans = 0x7ffb768e54e8 allocator = 0x7ffb768e33e0 status = <optimized out> i = <optimized out> lr = <optimized out> pollset = 0x7ffb768e3988 sbh = 0x7ffb768e3980 last_poll_idx = 1 lockfile = <optimized out> #17 0x00007ffb69e73a26 in make_child (s=0x7ffb76485340, slot=5) at prefork.c:800 pid = 0 #18 0x00007ffb69e746be in perform_idle_server_maintenance (p=<optimized out>) at prefork.c:902 i = <optimized out> idle_count = <optimized out> ws = <optimized out> free_length = <optimized out> free_slots = {5, 32763, 513, 0 <repeats 29 times>} last_non_dead = <optimized out> total_non_dead = <optimized out> #19 prefork_run (_pconf=<optimized out>, plog=<optimized out>, s=<optimized out>) at prefork.c:1090 status = 32763 pid = {pid = -1, in = 0x7ffb65dec4cf <_zend_hash_add_or_update+895>, out = 0x20765a2be0, err = 0x14} child_slot = <optimized out> exitwhy = (APR_PROC_EXIT | unknown: 1710018720) processed_status = <optimized out> index = <optimized out> remaining_children_to_start = 0 rv = <optimized out> #20 0x00007ffb7471500e in ap_run_mpm (pconf=0x7ffb7645c158, plog=0x7ffb76489378, s=0x7ffb76485340) at mpm_common.c:96 pHook = 0x7ffb76559bc8 n = 0 rv = -1597786112 #21 0x00007ffb7470e5d6 in main (argc=2, argv=0x7fffedfd99a8) at main.c:777 c = 68 'D' showcompile = 0 showdirectives = 0 confname = 0x7ffb7474b08f "conf/httpd.conf" def_server_root = 0x7ffb7474b084 "/etc/httpd" temp_error_log = 0x0 error = <optimized out> process = 0x7ffb7645a238 pconf = 0x7ffb7645c158 plog = 0x7ffb76489378 ptemp = 0x7ffb76487368 pcommands = 0x7ffb7647e268 opt = 0x7ffb7647e358 rv = <optimized out> mod = 0x7ffb74969098 <ap_prelinked_modules+24> opt_arg = 0x7fffedfd9f6f "FOREGROUND" signal_server = <optimized out> ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=67687&edit=1