php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #67687 Crash or zend_mm_heap_corrupted error in opcache with OwnCloud 7 update
Submitted: 2014-07-26 00:53 UTC Modified: 2020-04-19 04:22 UTC
Votes:4
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: adamw at happyassassin dot net Assigned: cmb (profile)
Status: No Feedback Package: opcache
PHP Version: 5.5.15 OS: Fedora 20
Private report: No CVE-ID: None
View Developer Edit
 [2014-07-26 00:53 UTC] 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>

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-07-26 01:11 UTC] 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 06:44 UTC] 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-27 13:25 UTC] 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
 [2015-03-16 10:26 UTC] software-php at interfasys dot ch 
Still a problem on PHP 5.5.22
 [2020-04-07 10:22 UTC] cmb@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2020-04-07 10:22 UTC] cmb@php.net 
Can you still reproduce this crash with any of the actively
supported PHP versions[1]?

<https://www.php.net/supported-versions.php>
 [2020-04-19 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-2025 The PHP Group
All rights reserved. 		Last updated: Wed Apr 02 06:01:30 2025 UTC