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

From: Date: Wed, 13 Sep 2017 03:23:33 +0000
Subject: Bug #71135 [Com]: Random memory corruption with strings
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-211113@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:         nick at noodles dot net dot nz
 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:

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.


Previous Comments:
------------------------------------------------------------------------
[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

------------------------------------------------------------------------
[2017-09-13 01:59:02] nick at noodles dot net dot nz

We've always had file cache disabled for what it's worth.

------------------------------------------------------------------------
[2017-09-13 01:46:03] jjones at smugmug dot com

Today we've been running tests with "opcache.file_cache=" disabled.  We were using
that feature before.

I have not been able to crash "php-fpm" since making that change, even on a system with a
tightly constrained "interned string buffer" setting.

So IMO if you're using Opcache file backed caching, it's worth trying to run with it
disabled.

------------------------------------------------------------------------
[2017-09-13 01:22:28] nick at noodles dot net dot nz

I'm still seeing problems as well. So far I've disabled huge code pages and changed
opcache to not check timestamps (code deploys now fire an opcache_reset() on each webserver).

Is it possible to disable interned strings?

Also, should we be adding comments to this bug or creating a new one (being that this is closed)?

------------------------------------------------------------------------
[2017-09-12 17:21:51] mike@php.net

After many more tests, it seems it rather depends on the moon phase, because I cannot reproduce
anymore.

Looking into the write of uninitialized bytes next.

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


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 (#211113) next »