Skip to content

Conversation

@EdmondDantes
Copy link

@EdmondDantes EdmondDantes commented Jan 15, 2026

  • this branch may be incorrect. It might need to be moved to PHP8.6?

In the current Win32 shmop implementation, messages like

Unable to attach or create shared memory segment "no error" are printed.

This happens because the errno variable is not populated correctly on Win32.

This change fixes the Win32 logic so that error messages roughly match the actual outcome. Unfortunately, it is still not perfect, as there is a case with differing segment sizes that is handled as an invalid descriptor.

edorian and others added 4 commits December 16, 2025 16:59
Add proper errno setting for all error paths in shmget() on Windows.
Introduces tsrm_set_errno_from_win32_error() to map Windows error codes
to POSIX errno values (EACCES, ENOMEM, EINVAL, EEXIST, ENOENT).

This ensures that shmop_open() can provide meaningful error messages
to users instead of "No error" when operations fail.

Tests added to verify errno mapping for different error conditions.
Set errno for error conditions in shmdt() and shmctl():
- EINVAL for invalid segment address/key
- Windows error mapping for UnmapViewOfFile failures
- EINVAL for unknown shmctl commands

This completes errno handling for all shmop system calls on Windows.
Add proper handle cleanup when marking shared memory segment for deletion.
Previously, shmctl(IPC_RMID) only marked the segment by setting key to -1
but did not close the Windows file mapping handle, causing the segment to
persist in the system.

This led to errors when trying to reopen segments with the same key:
- Segment remained accessible via OpenFileMapping()
- But had key = -1, failing validation checks
- Resulted in "Invalid argument" errors

Now properly closes the handle, allowing Windows to destroy the named
mapping object when no processes are attached, matching POSIX semantics
where IPC_RMID marks segment for deletion.

Fixes issue where shmop_open() with 'c' flag fails after shmop_delete().
@iluuu1994
Copy link
Member

iluuu1994 commented Jan 15, 2026

this branch may be incorrect. It might need to be moved to PHP8.6?

You should effectively never target a patch. If something needs to be included in a patch that is already branched, the commit will be cherry-picked by the release manager. So, if this fixes a bug and the patch isn't risky, you should target PHP-8.4, otherwise master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants