opcache.interned_strings_buffer = 4096 is ignored and using default (PHP8) + segfault (PHP7+PHP5)

[ShaiMagal]

Description

Hi,

if I set opcache.interned_strings_buffer = 2048 or other lower value everything is fine. (working well)

If I set opcache.interned_strings_buffer = 4096 and reload PHP FPM I got problem.

Two cases:
PHP FPM 8.3.3 - ignoring value and set for default value 8 (no error log info in syslog or php fpm log)

PHP FPM 5.6.40 (PHP 7.x is segfault as well) - segfault (I know, obsolete version, only for context - if I set lower value, no problem here) - here is the log from syslog php 5.6
Mar 5 14:06:03 s08 kernel: [5656531.610602] show_signal_msg: 6 callbacks suppressed
Mar 5 14:06:03 s08 kernel: [5656531.610604] php-fpm5.6[924861]: segfault at 30 ip 00005609add607d1 sp 00007ffdb3329e30 error 4 in php-fpm5.6[5609adbc6000+242000]
Mar 5 14:06:03 s08 kernel: [5656531.610612] Code: 19 48 01 c3 48 89 d8 48 8d 4a 01 48 c1 e0 05 48 01 d8 48 0f be 1a 48 01 c3 48 89 d8 48 c1 e0 05 48 01 d8 48 0f be 19 48 01 c3 <48> 8b 47 30 89 da 23 57 04 48 8b 2c d0 48 85 ed 74 5d 45 89 ef eb

Environment:
Ubuntu 22 LTS
physical memory 1TB
opcache.memory_consumption = 25000

I didn't have oportunity to test PHP 7.x but in every PHP version it's not working. 2 possible options:

• use default 8
• segfault

Do you need more informations?

Thank you.

PHP Version

8.3.3

Operating System

Ubuntu 22.04 LTS

[devnexen]

Juste a note here about actively supported PHP versions.

[damianwadley]

Are you sure there's no messages in the FPM logs? And that you have those logs set up properly, of course?

If php-fpm is disregarding your request for 4 GB (the setting is measured in MBs) of interned_strings_buffer then it should write a warning to the FPM log saying

opcache.interned_strings_buffer must be less than or equal to %d, %d given.

where the first number is the maximum value permitted - which is almost certainly going to be less than 4096.

---

@devnexen: You removed Needs Triage but didn't substitute another Status label. Was that intentional? There should probably always be a Status assigned, be that Needs Triage or Verified or whatever.

[devnexen]

I admit I did, I thought assigning PHP component label was sufficient, will remember for next time, cheers.

[arnaud-lb]

Opcache has its own logging system controlled by opcache.log_verbosity_level and opcache.error_log. With opcache.log_verbosity_level=3, we can see the following being logged:

Warning opcache.interned_strings_buffer must be less than or equal to 4095, 4096 given.

This warning was added in 8.2: #9260. In hindsight, this should probably be an error.

[ShaiMagal]

@arnaud-lb Yea, it is good catch, totally coresponding our situation (#9260).
We see in logs now (we try 9999 only for test):
"Warning opcache.interned_strings_buffer must be less than or equal to 4095, 9999 given."

DETAILED TEST RESULTS:
PHP 8.3 - 2048 = working well
PHP 8.3 - 4095 = working well
PHP 8.3 - 4096 = automatically set to 8
PHP 7.4 - 2048 - working well
PHP 7.4 - 4095 - segfault
PHP 7.4 - 4096 - segfault
PHP 5.6 - 2048 - working well
PHP 5.6 - 4095 - segfault
PHP 5.6 - 4096 - segfault

• We know, 5.x-7.x is totally obsolete, only for compare, of course we don't care about this versions.

We have very busy servers, with 2TB+ memory each and we "need" this value higher, for example 10GB in reality.

So, what are options, how to solve this problem? I think, 4095 "hardcoded" is max value if I understand this well?

Or we miss something?

[ShaiMagal]

@devnexen I know, 5.6 is obsolete - I use it only for compare, we care about actual versions (PHP 8.1+) of course :)

[arnaud-lb]

The limitation comes from the fact we use 32bit offsets to the interned strings buffer. It should be possible to remove this limitation by switching to 64bit offsets (which would increase the memory usage), or by partitioning the buffer internally.

[ShaiMagal]

OK, understand. So this isn't bug, but "feature", yea?

Btw, do you know why we have segfault for this settings?
PHP 7.4 - 4095 - segfault (2048 working)
(I know, PHP 7.4 isn't supported, but more than 50% of our customers have this version already)

Thank you.

[arnaud-lb]

Yes I consider this a feature request because it works as indented.

7.4 fails earlier because it uses different types internally.

After looking at it, it appears that we could increase the limit to 32GB in 8.4 without adding memory overhead or increasing complexity, by taking profit of the fact that offsets are 8-bytes aligned.

BTW, could you describe your use-case? Do you know how many interned strings you have in 4GB? Are you running a shared hosting?

[arnaud-lb]

@ShaiMagal could you check if #13676 helps?

[ShaiMagal]

@arnaud-lb We have hundreds customers on every server. Yes, we are webhosting company.
I don't know how many strings is there, because opcache/phpinfo show onl "Used memory" and "Free memory", but not number of strings. So we don't know. We see only this, no more information:

If you know how we can gather more info, let me know and I can ask administrators to do this.

Interned Strings Used memory | 2147483640
Interned Strings Free memory | 8

Unfortunatelly, we can't test #13676 , because we don't compile, we are using PPA from Ondrej Sury (packages).

[arnaud-lb]

Closing as implemented by #13676

[ShaiMagal]

@arnaud-lb thank you! What version of PHP will get this patch?

[arnaud-lb]

This will be in 8.4

[ShaiMagal]

@arnaud-lb ah, so bad, i hope we can give it to all 8.x to benefit from this feature soon.
Php 8.4 we will benefit from this approximatelly from 2026 :(

Isn't there possibility how to merge this to older versions like 8.1/8.2 as well? If yes, we can benefit from this immediatelly. And not onle we, but all webhostings with same use case :)

[arnaud-lb]

This is considered a new feature, or at least not a bug fix, so this can not be merged in a released version. The change should apply cleanly to 8.x however, and the source of the Ondrej Sury packages are available (via apt source php8.3 if you enable the src repository), so it shouldn't be hard to rebuild the packages with one more patch.

[ShaiMagal]

Understand