|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #65987 memory leak and handle leak in shmop
Submitted: 2013-10-29 00:42 UTC Modified: 2020-05-13 13:48 UTC
Avg. Score:4.0 ± 1.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: sakamoto dot ta at saxa dot co dot jp Assigned:
Status: Analyzed Package: *Extensibility Functions
PHP Version: Irrelevant OS: Windows
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: sakamoto dot ta at saxa dot co dot jp
New email:
PHP Version: OS:


 [2013-10-29 00:42 UTC] sakamoto dot ta at saxa dot co dot jp
OS´╝ÜWindows 2008 Server R2
PHP:Version 5.3.9

I received an answer and add shmop_delete the case () in Bug # 65949, but it does not improve.
Application error occurs when continue to operate the following script.

When I call the () shm_close the () shm_open, handle name
 \BaseNamedObjects\TSRM_SHM_DESCRIPTOR:x and 
remains without being released. 
The amount of memory used will continue to increase.

This problem does not occur on Linux.

Test script:
    $shm_id = 0;
    $hex_shm_id = 0xff3;
    $write_d1 = "test #1 of the shmop() extension";
    $write_d2 = "test #2 append data to shared memory segment";
    for( ; ; )
        echo "shm open for create : ";
        $shm_id = shmop_open($hex_shm_id, "c", 0644, 1024);
        if (!$shm_id) {
        } else {
            echo "ok[".$shm_id."]\n";

        echo "shm size is: " . ($shm_size = shmop_size($shm_id)) . "\n";
        echo "shm write test #1: ";

        $written = shmop_write($shm_id, $write_d1, 0);
        if ($written != strlen($write_d1)) {
            echo "failed\n";
        } else {
            echo "ok\n";
        echo "data in memory is: " . shmop_read($shm_id, 0, $written) . "\n";
        // Add Next 2 Lines
        $delete_result = shmop_delete($shm_id);
        echo "shmop_delete return value [".$delete_result."]\n";
        $shm_id = 0;


Expected result:
Memory leak and handle leak does not occur.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2016-10-07 13:06 UTC]
-Package: Unknown/Other Function +Package: *Extensibility Functions
 [2018-09-18 17:05 UTC]
-Status: Open +Status: Verified -Operating System: Windows 2008 Server R2 +Operating System: Windows
 [2018-09-18 17:05 UTC]
I can confirm that shmop_delete() still does not work on Windows
with current master.

The culprit appears to be the refcount (.shm_nattac) check[1]; it
seems to me this can't possibly work, since shmop_open() calls
shmat() which increases the refcount, so it is always greater than

[1] <>
 [2020-05-13 13:48 UTC]
-Status: Verified +Status: Analyzed
 [2020-05-13 13:48 UTC]
Well, the actual reason for this behavior is that our Windows
implementation of the shm*() functions is rather different from
the POSIX semantics, where shared memory is persistent, i.e. it is
retained even if all handles have been closed.  That is not the
case on Windows; if the last handle is closed, the shared memory
is freed.  So shmop_delete() is actually supposed to be a NOP

However, shmop_close() does not close all handles to the shared
memory on Windows, because re-opening from the same process would
no longer be possible.  This cannot be changed in a revision
release due to BC concerns.

It may be reasonable to more closely match POSIX semantics in PHP
8.  This would require to create file mappings to actual files on
disk, instead of page-file backed memory.  As the shared memory
would then be persistent, shmop_close() could actually close all
handles, and shmop_delete() could be implemented in a way that
would delete the backing file on disk after all handles had been
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Jun 18 00:01:32 2024 UTC