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

From: Date: Sun, 07 Jan 2018 21:09:40 +0000
Subject: Bug #71135 [Com]: Random memory corruption with strings
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-213409@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:         jagoba at tapatalk dot com
 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:

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?


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

------------------------------------------------------------------------
[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.

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


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