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.