fix: insufficient shared memory available in Unity 6.6 beta#308
fix: insufficient shared memory available in Unity 6.6 beta#308mob-sakai wants to merge 1 commit into
Conversation
|
|
📝 WalkthroughWalkthroughThis PR adds a ChangesDocker Shared Memory Size Configuration
Estimated code review effort: 1 (Trivial) | ~3 minutes Possibly related issues
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint install failed. For unrecoverable errors, disable the tool in CodeRabbit configuration. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/model/docker.ts`:
- Line 78: The Docker run command construction in docker.ts is still
unconditionally adding --shm-size=1025m, which breaks native Windows containers
and can exceed a user-provided dockerMemoryLimit. Update the logic that builds
the docker run arguments so --shm-size is only included for Linux containers,
and ensure the value is derived from or capped below dockerMemoryLimit rather
than hard-coded. Use the existing Docker command assembly path in the run helper
to keep the platform-specific behavior isolated.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: a170fa75-39f2-45c8-8a88-ab5ccda7a0c6
⛔ Files ignored due to path filters (3)
dist/index.jsis excluded by!**/dist/**dist/index.js.mapis excluded by!**/dist/**,!**/*.mapdist/licenses.txtis excluded by!**/dist/**
📒 Files selected for processing (1)
src/model/docker.ts
| ).join(';'); | ||
|
|
||
| return `docker run \ | ||
| --shm-size=1025m \ |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Find default/allowed values for dockerMemoryLimit to check for conflicts with the new shm-size
rg -n 'dockerMemoryLimit' --type=ts -C3Repository: game-ci/unity-test-runner
Length of output: 163
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the docker model and all references to dockerMemoryLimit
git ls-files | rg '(^|/)src/model/docker\.ts$|(^|/)src/.*\.ts$|package\.json$|README\.md$'
printf '\n--- docker.ts outline ---\n'
ast-grep outline src/model/docker.ts --view expanded || true
printf '\n--- docker.ts relevant lines ---\n'
sed -n '1,240p' src/model/docker.ts
printf '\n--- dockerMemoryLimit references ---\n'
rg -n 'dockerMemoryLimit' src . -g '!node_modules' -g '!dist' -g '!build' -C 3 || trueRepository: game-ci/unity-test-runner
Length of output: 14267
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect Docker flag usage and any Windows-specific handling
rg -n --hidden --glob '!node_modules' --glob '!dist' --glob '!build' \
--glob '!*.min.*' 'shm-size|windows|linux' src README.md package.json || trueRepository: game-ci/unity-test-runner
Length of output: 2359
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Check docker docs/comments around the chosen shm-size value if present in repo
rg -n '1025m|shm-size|--memory=' src README.md .github docs . || trueRepository: game-ci/unity-test-runner
Length of output: 50383
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Read the docker model and the parameter definition that supplies dockerMemoryLimit
printf '\n--- src/model/docker.ts ---\n'
sed -n '1,220p' src/model/docker.ts
printf '\n--- files mentioning dockerMemoryLimit or memory defaults ---\n'
rg -n --hidden --glob '!node_modules' --glob '!dist' --glob '!build' \
'dockerMemoryLimit|memoryLimit|--memory=' src test .github README.md package.json || trueRepository: game-ci/unity-test-runner
Length of output: 7259
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Read the exact file under review and surrounding config definitions
printf '\n--- src/model/docker.ts (1-220) ---\n'
cat -n src/model/docker.ts | sed -n '1,220p'
printf '\n--- project-wide exact matches for --memory and shm-size ---\n'
rg -n --hidden --glob '!node_modules' --glob '!dist' --glob '!build' \
-- '--memory=|shm-size|dockerMemoryLimit' src .github README.md package.json || trueRepository: game-ci/unity-test-runner
Length of output: 8503
🌐 Web query:
Docker --shm-size Windows containers supported /dev/shm official docs
💡 Result:
The --shm-size flag, which controls the size of the /dev/shm shared memory filesystem in a container, is natively a Linux-based feature and is not supported for native Windows containers [1][2]. Windows containers do not utilize /dev/shm [3][4]. The /dev/shm directory is a characteristic of Linux systems (a tmpfs filesystem); Windows containers use different, native Windows mechanisms for inter-process communication and shared memory [4]. If you are using Docker Desktop on Windows with the WSL2 backend (which runs Linux containers), the --shm-size flag is generally honored because the underlying containers are running on a Linux kernel within the WSL2 utility VM [5][6]. However, when running native Windows containers, this flag has no functional effect as the architecture does not support the Linux-style shared memory mount [1][2]. Users attempting to share memory between native Windows containers or with the host often encounter limitations, as common Linux-based workarounds (such as mounting /dev/shm) are not applicable [3][7][4].
Citations:
- 1: https://docs.docker.com/reference/cli/docker/container/run/
- 2: https://github.com/docker/cli/blob/613ab8b2d5f1a1d723617ddea2661b10d749aeae/docs/reference/commandline/run.md
- 3: https://stackoverflow.com/questions/71503406/how-can-a-tmpfs-folder-in-docker-be-mounted-and-shared-on-windows
- 4: Shared memory between containers docker/for-win#2208
- 5:
--ipc=shareableor--ipc=hostin WSL2 does not share files in container's/dev/shm/docker/for-win#12988 - 6: Can't mount /dev/shm/ from Windows environment when using WSL2 backend docker/for-win#7455
- 7: Shared memory between containers does not work as it should: --ipc=host --isolation=process --user ContainerAdministrator docker/for-win#10862
🌐 Web query:
site:docs.docker.com --shm-size Windows containers /dev/shm
💡 Result:
The --shm-size option is a Linux-specific feature for Docker containers [1][2][3]. It is used to configure the size of the /dev/shm (shared memory) partition, which is a common construct in Linux-based operating systems [3]. Windows containers do not have a /dev/shm directory, nor do they support the --shm-size flag [1][4][2]. Windows uses different mechanisms for inter-process communication (IPC) and memory management [5]. Consequently, attempting to use --shm-size with a Windows container will result in an error or be ignored, as the underlying architecture does not rely on a shared memory filesystem mounted at that path.
Citations:
- 1: https://docs.docker.com/reference/cli/docker/container/run/
- 2: https://docs.docker.com/engine/containers/run/
- 3: https://docs.docker.com/reference/compose-file/services/
- 4: https://docs.docker.com/reference/cli/docker/container/run/?highlight=gpus%3Dall
- 5: https://docs.docker.com/reference/cli/docker/service/create/
🌐 Web query:
site:docs.docker.com "shm-size" Windows containers
💡 Result:
The --shm-size option is specific to Linux containers and is used to configure the size of the /dev/shm (shared memory) partition [1]. This concept does not apply to Windows containers because Windows does not use a /dev/shm filesystem [2][1][3]. When running Windows containers, the --shm-size flag is generally ignored or produces errors because the underlying architecture for shared memory management differs fundamentally from the POSIX-based shared memory implementation found in Linux [2][4]. Windows containers rely on native Windows memory management primitives (such as named shared memory sections) rather than the filesystem-backed shared memory approach used in Linux [3]. If your application requires shared memory while running in a Windows container, you should ensure it is designed to use native Windows APIs for inter-process communication instead of relying on /dev/shm paths.
Citations:
- 1: https://docs.docker.com/engine/containers/run/
- 2: https://docs.docker.com/reference/cli/docker/container/run/
- 3: https://docs.docker.com/reference/cli/docker/container/run/?highlight=gpus%3Dall
- 4: https://docs.docker.com/reference/cli/docker/container/create/
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Read the docker memory default logic and its user-facing description
printf '\n--- src/model/input.ts (100-135) ---\n'
sed -n '100,135p' src/model/input.ts
printf '\n--- action.yml dockerMemoryLimit block ---\n'
sed -n '70,90p' action.ymlRepository: game-ci/unity-test-runner
Length of output: 2940
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Check for any tests that constrain dockerMemoryLimit values
rg -n 'dockerMemoryLimit|memoryMultiplier|totalmem|1025m|shm-size' src/model/*.test.ts src/model/input.ts action.yml -C 2 || trueRepository: game-ci/unity-test-runner
Length of output: 1719
🌐 Web query:
Docker shm-size memory limit OOM kill shared memory container memory limit docs
💡 Result:
In Docker, the --shm-size flag configures the size of the /dev/shm (POSIX shared memory) filesystem [1][2]. By default, Docker allocates 64MB of shared memory to each container [1][3]. Relationship to OOM Kills: Increasing --shm-size allocates memory that counts toward the total memory usage of the container [4][5]. If a container has a hard memory limit set via --memory, the shared memory (shm) is included in this total budget [6][7]. If the combined memory usage—including the application heap, page cache, and the allocated shared memory—exceeds the container's --memory limit, the Linux kernel will invoke the OOM (Out Of Memory) killer to terminate processes within that container [4][6]. Key Considerations: 1. Memory Accounting: On modern Linux systems (cgroups v2), the kernel tracks all memory allocated by the container, including anonymous memory, file-backed page cache, and shmem [6][7]. Setting a large --shm-size (e.g., 16GB) without ensuring your --memory limit is sufficiently higher will likely lead to immediate OOM kills if the application attempts to utilize that shared memory [5]. 2. IPC Namespace Isolation: The --shm-size setting is only effective when the container uses its own IPC namespace (the default behavior) [2]. If you configure a container to use the host's IPC namespace (via --ipc=host), the container will use the host's /dev/shm configuration instead, and the --shm-size flag is ignored [2]. 3. OOM Detection: When a container is OOM killed due to hitting its memory limit, it will exit with code 137 [4][7]. You can verify this by checking docker inspect <container_id> for "OOMKilled": true [4][7]. 4. Best Practices: If your application (e.g., Chrome, PostgreSQL, ML frameworks) requires significant shared memory, ensure your --memory limit accounts for both the expected application workload and the configured --shm-size [4][1]. Avoid disabling the OOM killer (--oom-kill-disable), as this can lead to memory exhaustion and system instability rather than resolving the underlying memory pressure [8][6].
Citations:
- 1: https://last9.io/blog/how-to-configure-dockers-shared-memory-size-dev-shm/
- 2: https://blog.mikihands.com/en/whitedec/2025/11/5/docker-shm-size-ipc/
- 3: https://datawookie.dev/blog/2021-11-09-shared-memory-docker/
- 4: https://cr0x.net/en/docker-oom-memory-limits/
- 5: memory limit is incorrectly calculated when setting docker shm_size hashicorp/nomad#17425
- 6: https://www.matthewswong.com/en/blog/linux-cgroups-container-resource-limits/
- 7: https://www.netdata.cloud/guides/docker/docker-memory-limits/
- 8: https://docs.docker.com/engine/containers/resource_constraints
🏁 Script executed:
#!/bin/bash
set -euo pipefail
sed -n '110,135p' src/model/input.ts
printf '\n'
sed -n '70,90p' action.ymlRepository: game-ci/unity-test-runner
Length of output: 2282
Remove --shm-size from the Windows docker run path.
--shm-size is Linux-only, so it shouldn’t be passed to native Windows containers. The hard-coded 1025m also needs to stay below any user-supplied dockerMemoryLimit, or the Linux container can hit its memory cap.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/model/docker.ts` at line 78, The Docker run command construction in
docker.ts is still unconditionally adding --shm-size=1025m, which breaks native
Windows containers and can exceed a user-provided dockerMemoryLimit. Update the
logic that builds the docker run arguments so --shm-size is only included for
Linux containers, and ensure the value is derived from or capped below
dockerMemoryLimit rather than hard-coded. Use the existing Docker command
assembly path in the run helper to keep the platform-specific behavior isolated.
1 participant
Changes
--shm-size=1025mas an argument todocker runand tests and builds completed successfully.Related Issues
Related PRs
Successful Workflow Run Link
PRs don't have access to secrets so you will need to provide a link to a successful run
of the workflows from your own repo.
game-ci/unity-test-runner@mainmob-sakai/unity-test-runner@2daca32470ee589ddedc42051ce1472733177d20(fixed)Checklist
in the documentation repo)
Summary by CodeRabbit