|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #68121 ZTS opcache inconsistent memory alloc/free semantics
Submitted: 2014-09-30 23:01 UTC Modified: 2015-04-19 04:22 UTC
From: rrh at newrelic dot com Assigned: dmitry (profile)
Status: No Feedback Package: opcache
PHP Version: 5.6.0 OS: linux
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:
Solve the problem:
5 + 37 = ?
Subscribe to this entry?

 [2014-09-30 23:01 UTC] rrh at newrelic dot com
In php 5.6.0 (that's all I've looked at), the opcache related function
does no interning, and returns the argument string if compiled for ZTS.

Unfortunately, the related free-like function
doesn't special case for ZTS, and still appears to free as if the string were created by internment.

If you compile php 5.6 in ZTS mode, using a modern gcc (such as 4.9.1) which supports -fsanitize=address (aka "asan"), and then run in cgi mode, you'll see that the asan runtime system reports an illegal free stemming from the call to accell_clean_non_persistent_constant

Here's a gdb backtrace:#0  0x00007f909ae21bb9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007f909ae24fc8 in __GI_abort () at abort.c:89
#2  0x00007f909ae5ee14 in __libc_message (do_abort=do_abort@entry=1, 
    fmt=fmt@entry=0x7f909af6d668 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
#3  0x00007f909ae69b77 in malloc_printerr (action=<optimized out>, str=0x7f909af6d9e8 "munmap_chunk(): invalid pointer", 
    ptr=<optimized out>) at malloc.c:4996
#4  0x00007f909453be00 in accel_clean_non_persistent_constant (c=0x604000048850, tsrm_ls=0x60300000efb0)
    at /opt/nr/lamp/build/php-5.6.0-zts/ext/opcache/ZendAccelerator.c:2327
#5  0x00007f909eebe633 in zend_hash_reverse_apply (ht=0x607000054bf0, 
    apply_func=0x7f909453bdcb <accel_clean_non_persistent_constant>, tsrm_ls=0x60300000efb0)
    at /opt/nr/lamp/build/php-5.6.0-zts/Zend/zend_hash.c:729
#6  0x00007f909453c2d2 in zend_accel_fast_shutdown (tsrm_ls=0x60300000efb0)
    at /opt/nr/lamp/build/php-5.6.0-zts/ext/opcache/ZendAccelerator.c:2360
#7  0x00007f909453c3fc in accel_deactivate () at /opt/nr/lamp/build/php-5.6.0-zts/ext/opcache/ZendAccelerator.c:2385
#8  0x00007f909ee322b3 in zend_extension_deactivator (extension=0x611000073550, tsrm_ls=0x60300000efb0)
    at /opt/nr/lamp/build/php-5.6.0-zts/Zend/zend_execute_API.c:101
#9  0x00007f909ee4bbc0 in zend_llist_apply (l=0x7f90a0ec4b20 <zend_extensions>, func=0x7f909ee32267 <zend_extension_deactivator>, 
    tsrm_ls=0x60300000efb0) at /opt/nr/lamp/build/php-5.6.0-zts/Zend/zend_llist.c:191
#10 0x00007f909ee3468f in shutdown_executor (tsrm_ls=0x60300000efb0) at /opt/nr/lamp/build/php-5.6.0-zts/Zend/zend_execute_API.c:246
#11 0x00007f909ee7d4ec in zend_deactivate (tsrm_ls=0x60300000efb0) at /opt/nr/lamp/build/php-5.6.0-zts/Zend/zend.c:949
#12 0x00007f909ec65e65 in php_request_shutdown (dummy=0x0) at /opt/nr/lamp/build/php-5.6.0-zts/main/main.c:1884
#13 0x00007f909f2504a5 in main (argc=5, argv=0x7fff9fe0bdc8) at /opt/nr/lamp/build/php-5.6.0-zts/sapi/cgi/cgi_main.c:2508


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2014-09-30 23:01 UTC]
-PHP Version: master-Git-2014-09-30 (Git) +PHP Version: 5.6.0
 [2014-10-15 16:04 UTC]
-Assigned To: +Assigned To: dmitry
 [2014-10-15 16:57 UTC]
I have no idea, that can be wrong (I'll wait for Fedora release with gcc 4.9)

Is it reproducible with valgrind?

USE_ZEND_ALLOC=0 valgrind --db-attach=yes php-cgi ...
 [2015-04-06 19:57 UTC]
-Status: Assigned +Status: Feedback
 [2015-04-06 19:57 UTC]
I can't reproduce this with GCC 4.9.2.
 [2015-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-2021 The PHP Group
All rights reserved.
Last updated: Mon Nov 29 21:03:45 2021 UTC