Bug #71135 [Com]: Random memory corruption with strings

From: Date: Tue, 14 May 2019 13:04:42 +0000
Subject: Bug #71135 [Com]: Random memory corruption with strings
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-220852@lists.php.net to get a copy of this message 
Edit report at https://bugs.php.net/bug.php?id=71135&edit=1

 ID:                 71135
 Comment by:         irker@php.net
 Reported by:        iquito at gmx dot net
 Summary:            Random memory corruption with strings
 Status:             Closed
 Type:               Bug
 Package:            opcache
 Operating System:   Debian Jessie
 PHP Version:        7.0.0
 Assigned To:        laruence
 Block user comment: N
 Private report:     N

 New Comment:

See this patch: http://git.php.net/?p=php-src.git;a=commit;h=5c4d125d4c2976236e2ecddd1d8c6e7b113ec482

It must fix some cases with broken opcache after reset.


Previous Comments:
------------------------------------------------------------------------
[2018-01-07 23:24:07] jjones at smugmug dot com

I just heard (today) about and reviewed the patches described here:

https://bugs.php.net/bug.php?id=75579

and from the description of that issue, and what the fix does, I think it's entirely possible
that it will our crashes with file backed caching.  I haven't had time to test it, and
we're running just fine with file based caching disabled for now.  But I wanted to connect the
dots for other people following this bug.

------------------------------------------------------------------------
[2018-01-07 21:09:36] jagoba at tapatalk dot com

We still have this issue. We are now on php 7.2.0, our opcache is configured to 256mb and we not
using file_cache. I saw that in php master there is a commit to change how interned strings works.
Is there posibility that code be merged into next version 7.2.2? will it solve the problem?

------------------------------------------------------------------------
[2017-09-13 04:08:10] rasmus@php.net

It depends on your code, of course, but for a large site you probably need to go to 128M or 256M for
the string buffer.

------------------------------------------------------------------------
[2017-09-13 03:23:31] nick at noodles dot net dot nz

Thanks, I've bumped it from 8MB -> 32MB and will monitor it. I can't see it hitting the
8MB limit when the corruption occurs, but it gets close.

------------------------------------------------------------------------
[2017-09-13 02:32:36] rasmus@php.net

You really don't want to run without the string buffer. You also don't want to fill it.
You will be leaving quite a bit of performance on the table if you do. Instead of turning it off, I
would jack it way up if I were you.

At Etsy we deploy dozens of times every day and do not do any sort of cache reset. But there is a
nightly log rotation that does a graceful restart so everything does get cleaned up once per day.
And these dozens of deploys are atomic and cache-preserving in the sense that I switch back and
forth between A and B docroots so only files changed across deploys need to be recompiled. I
describe the theory behind it here: https://codeascraft.com/2013/07/01/atomic-deploys-at-etsy/

For php-fpm behind nginx see the comments of that article and the magic nginx config variable
$realpath_root

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=71135


--
Edit this bug report at https://bugs.php.net/bug.php?id=71135&edit=1

Thread (52 messages)

« previous php.bugs (#220852) next »