Shared memory descriptors are not closed after PHP program execution is complete.

[CoderAImen]

Description

Extension SHMOP.

shm_id = shmop_open($r, "c", 0644,1024000); ?>

When the web server is running for a long time, the number of open descriptors reaches 15 million or more. As a result, the web server complains about the lack of resources.

Shared memory descriptors are not closed after PHP program execution is complete.

Apache 2.4.62 PHP 8.4(php8apache2_4.dll) Windows 11.

PHP Version

PHP 8.4

Operating System

Windows 11

[cmb69]

php-src/TSRM/tsrm_win32.c

Lines 751 to 754 in bf5e6c5

	if (shm->descriptor->shm_nattch <= 0) {
	ret = UnmapViewOfFile(shm->descriptor) ? 0 : -1;
	shm->descriptor = NULL;
	}

It seems to me that we need to unmap unconditionally, but should close the handle if the refcount drops to zero (the latter might not be necessary).

[CoderAImen]

php-src/TSRM/tsrm_win32.c

Lines 751 to 754 in bf5e6c5

	if (shm->descriptor->shm_nattch <= 0) {
	ret = UnmapViewOfFile(shm->descriptor) ? 0 : -1;
	shm->descriptor = NULL;
	}

It seems to me that we need to unmap unconditionally, but should close the handle if the refcount drops to zero (the latter might not be necessary).

php-src/TSRM/tsrm_win32.c

Lines 686 to 691 in bf5e6c5

	shm = shm_get(key, NULL);
	if (!shm) {
	CloseHandle(shm_handle);
	return -1;
	}
	shm->segment = shm_handle;

At this point the open Handle is lost, since no one closed shm->segment.

[dktapps]

Is this a problem outside of shmop? It might explain some strange "out of resources" user issues I've seen in my applications over the years. Basically, is OPcache also affected by this?

[cmb69]

OPcache should not be affected, but the underlying emulation of POSIX shared memory primitives is in tsrm_win32.c, and can be used by other clients than ext/shmop (for instance, it is also used by ext/sysvshm).