의도된 쓰기는 그대로 둡니다. codex·hermes purge 의 DELETE, opencode purge 의 옛 행 정리가 여기에 해당합니다.
MAM 자신의 DB(agent-sessions.db, atomic_yaml·state·verify_session·loop runner)도 대상이 아닙니다.
제안
opencode 의 _ro_connect(사이드카 상태에 따라 mode=ro / mode=ro&immutable=1 / -shm 없는 -wal 은 임시 복사본)를 공용 helper 로 옮깁니다. 예: lib_py/agents/base.py.
위 표의 조회를 그 helper 로 바꿉니다.
회귀 테스트를 추가합니다. 네 가지 상태(clean, 남겨진 사이드카, -shm 없는 -wal, 쓰는 중)에서 조회 결과가 맞고 디렉터리 목록이 바뀌지 않는지 확인합니다. macOS 의 persistent WAL 을 고려해, clean 상태는 테스트가 사이드카를 지워서 만듭니다.
위 홈 가드 오류의 원인을 확인합니다. agy 조회 경로에서 다른 워크스페이스의 대화 DB 를 여는 경우가 있는지 봅니다.
참고
Issue #60 / PR #62: opencode 의 같은 수정과 테스트(tests/test_issue60_linux_fixes.py)
Issue #28: Linux 의 agy purge 테스트 실패(원인 미조사). 이 이슈와 겹칠 수 있습니다.
## 증상
MAM 은 에이전트의 대화 DB(SQLite)를 **조회만 할 때도 쓰기 가능 모드**(`sqlite3.connect(path)`)로 엽니다. 이렇게 열면 조회만 해도 에이전트 DB 옆의 파일이 바뀝니다.
- **macOS**: 시스템 SQLite 는 persistent WAL 로 동작해, WAL 모드 DB 를 열고 닫으면 `-wal`·`-shm` 을 만들고 그대로 남깁니다.
- **Linux**: 마지막 연결을 닫을 때 WAL 을 checkpoint 하고 `-wal`·`-shm` 을 지웁니다. 에이전트가 쓰는 중이면 그 에이전트의 파일을 건드리는 셈입니다.
opencode 는 v4.9.7(PR #62, Issue #60)에서 읽기 전용 열기 `_ro_connect` 로 바꿨습니다. agy·codex·hermes 는 아직 그대로입니다.
## 관련 관측 (원인 미확정)
v4.9.7 리뷰 중 macOS 전체 스위트에서 Issue #55 의 홈 가드가 오류를 냈습니다. **다른 워크스페이스**의 agy 대화 DB 옆에 `.db-wal`·`.db-shm` 이 새로 생겼고, 확인 시점에 그 DB 를 잡고 있는 프로세스는 없었습니다.
- 생긴 시각은 리뷰 루프와 스위트를 시작한 시각과 같았습니다.
- 아래 agy 조회 경로가 원인일 수 있지만 **확인하지 않았습니다**. 그 워크스페이스에서 agy 를 직접 썼을 가능성도 있습니다.
- 이 이슈에서 먼저 원인을 확인합니다.
## 대상 (조회 전용인데 쓰기 가능으로 여는 곳)
| 에이전트 | 위치 | 용도 |
|---|---|---|
| agy | `lib_py/agents/adapters/agy.py` (verify, `SELECT count(*) FROM steps`) | 대화 DB 검증 |
| codex | `lib_py/agents/adapters/codex.py` (`_find_rollout_via_db`, `discover`) | state DB 조회 |
| codex | `multi-agent-mux-status/scripts/status.sh` (codex 분기 2곳) | 상태 표시 |
| codex | `multi-agent-mux-monitor/scripts/reconcile.sh` (codex drift) | 불일치 보정 |
| hermes | `lib_py/agents/adapters/hermes.py` (`verify_artifact`, `discover`) | state DB 조회 |
| hermes | `multi-agent-mux-status/scripts/status.sh` (hermes 분기 2곳) | 상태 표시 |
| hermes | `multi-agent-mux-monitor/scripts/reconcile.sh` (hermes drift) | 불일치 보정 |
**대상이 아닌 곳**
- 의도된 쓰기는 그대로 둡니다. codex·hermes purge 의 `DELETE`, opencode purge 의 옛 행 정리가 여기에 해당합니다.
- MAM 자신의 DB(`agent-sessions.db`, `atomic_yaml`·`state`·`verify_session`·loop runner)도 대상이 아닙니다.
## 제안
1. opencode 의 `_ro_connect`(사이드카 상태에 따라 `mode=ro` / `mode=ro&immutable=1` / `-shm` 없는 `-wal` 은 임시 복사본)를 공용 helper 로 옮깁니다. 예: `lib_py/agents/base.py`.
2. 위 표의 조회를 그 helper 로 바꿉니다.
3. 회귀 테스트를 추가합니다. 네 가지 상태(clean, 남겨진 사이드카, `-shm` 없는 `-wal`, 쓰는 중)에서 조회 결과가 맞고 디렉터리 목록이 바뀌지 않는지 확인합니다. macOS 의 persistent WAL 을 고려해, clean 상태는 테스트가 사이드카를 지워서 만듭니다.
4. 위 홈 가드 오류의 원인을 확인합니다. agy 조회 경로에서 다른 워크스페이스의 대화 DB 를 여는 경우가 있는지 봅니다.
## 참고
- Issue #60 / PR #62: opencode 의 같은 수정과 테스트(`tests/test_issue60_linux_fixes.py`)
- Issue #28: Linux 의 agy purge 테스트 실패(원인 미조사). 이 이슈와 겹칠 수 있습니다.
- Issue #55: 실제 에이전트 홈 가드
실제 홈의 claude·opencode 폴더, herdr pane 목록, agy·codex·hermes 사이드카에 이 실행이 남긴 것은 없었다.
Linux 확인 요청
Linux 의 SQLite 는 닫을 때 -wal·-shm 을 지운다. 그래서 macOS 와 결과가 다를 수 있는 곳만 확인하면 된다. 실제 에이전트 홈의 DB 는 열지 말고, 임시 HOME 에서만 확인한다.
pytest tests/test_issue64_ro_connect.py 가 모두 통과한다. 특히 leftover(사이드카 쌍만 남음)·walonly 상태의 폴더 목록 비교가 맞는지 본다.
전체 스위트에서 새 실패가 없다. 알려진 test_issue10_13_purge.py agy 실패(#28)는 제외한다.
test_issue60_linux_fixes.py·test_issue60_opencode_v2.py 가 그대로 통과한다. opencode 가 공용 _ro_connect 를 import 한다.
(선택) 전체 스위트 전후로 실제 ~/.gemini/antigravity-cli/conversations·~/.hermes·~/.codex 의 -wal/-shm 목록을 ls 로 비교한다.
남은 비차단 (별도 처리 후보)
drift C(agy)는 last_conversations.json 이 다른 작업 공간에 기록한 대화도 후보로 받아 고정할 수 있다(기존 동작). 새 테스트 test_unpinned_agy_reconcile_… 가 이 동작을 단언하므로, 고칠 때 함께 바꾼다.
새 런타임 테스트의 reconcile 단계는 mock herdr 에 pane 이 없어 drift C 까지 가지 않는다. hermes·codex drift C 는 정적 검사가 지킨다.
immutable 읽기의 경쟁 창(ms 수준)이 세 에이전트로 넓어졌다. 실행 중인 에이전트의 DB 는 사이드카가 있어 mode=ro 로 읽는다.
## macOS 처리 결과 (PR #65, v4.9.8 병합)
**원인**
- `reconcile.sh` drift C(agy)는 고정되지 않은 agy 행이 있으면 호스트 공용 대화 폴더의 모든 `*.db` 를 후보로 본다.
- 다른 작업 공간의 대화도, 같은 작업 공간의 형제가 가진 것이 아니면 걸러지지 않는다.
- 그 뒤 `AgyAgentAdapter.verify_artifact` 가 `SELECT count(*) FROM steps` 를 쓰기 가능 연결로 실행했다.
- macOS SQLite 는 닫은 뒤에도 `-wal`·`-shm` 을 남긴다. 그래서 다른 작업 공간의 대화 DB 옆에 사이드카가 생겼다. `status.sh`·`create_session.sh` 도 reconcile 을 부르므로 같은 경로를 탄다.
**수정**
- `_ro_connect` 를 `lib_py/agents/base.py` 로 옮겼다. opencode 동작은 그대로다.
- 다음 조회가 이 함수를 쓴다:
- agy `verify_artifact`
- codex `_find_rollout_via_db`·`discover`
- hermes `verify_artifact`·`discover`
- `status.sh` hermes·codex
- `reconcile.sh` drift C hermes·codex
- `db_rows_naming` 기본 열기
- purge 의 의도된 쓰기와 MAM 자신의 DB 는 그대로다.
**검증 (macOS, Python 3.9.6)**
- `tests/test_issue64_ro_connect.py` 43개. base(v4.9.7)에서는 23개가 실패한다.
- 리뷰 4/4 PASS.
- 전체 2044 passed, 56 skipped, 실패 0.
- 실제 홈의 claude·opencode 폴더, herdr pane 목록, agy·codex·hermes 사이드카에 이 실행이 남긴 것은 없었다.
## Linux 확인 요청
Linux 의 SQLite 는 닫을 때 `-wal`·`-shm` 을 지운다. 그래서 macOS 와 결과가 다를 수 있는 곳만 확인하면 된다. 실제 에이전트 홈의 DB 는 열지 말고, 임시 HOME 에서만 확인한다.
- [ ] `pytest tests/test_issue64_ro_connect.py` 가 모두 통과한다. 특히 `leftover`(사이드카 쌍만 남음)·`walonly` 상태의 폴더 목록 비교가 맞는지 본다.
- [ ] 전체 스위트에서 새 실패가 없다. 알려진 `test_issue10_13_purge.py` agy 실패(#28)는 제외한다.
- [ ] `test_issue60_linux_fixes.py`·`test_issue60_opencode_v2.py` 가 그대로 통과한다. opencode 가 공용 `_ro_connect` 를 import 한다.
- [ ] (선택) 전체 스위트 전후로 실제 `~/.gemini/antigravity-cli/conversations`·`~/.hermes`·`~/.codex` 의 `-wal`/`-shm` 목록을 `ls` 로 비교한다.
## 남은 비차단 (별도 처리 후보)
- drift C(agy)는 `last_conversations.json` 이 다른 작업 공간에 기록한 대화도 후보로 받아 고정할 수 있다(기존 동작). 새 테스트 `test_unpinned_agy_reconcile_…` 가 이 동작을 단언하므로, 고칠 때 함께 바꾼다.
- 새 런타임 테스트의 reconcile 단계는 mock herdr 에 pane 이 없어 drift C 까지 가지 않는다. hermes·codex drift C 는 정적 검사가 지킨다.
- immutable 읽기의 경쟁 창(ms 수준)이 세 에이전트로 넓어졌다. 실행 중인 에이전트의 DB 는 사이드카가 있어 `mode=ro` 로 읽는다.
test_issue60_linux_fixes.py·test_issue60_opencode_v2.py 통과
실제 홈 사이드카 전후 비교
## Linux 확인 결과 (v4.9.8, ff8b381)
**환경:** Ubuntu 26.04.1 LTS (kernel 7.0), Python 3.14.7, SQLite 3.53.4. `XDG_*` 를 비우고 돌렸다.
| 항목 | 결과 |
| --- | --- |
| `tests/test_issue64_ro_connect.py` | 43 passed. 실패 없음. |
| `test_issue60_linux_fixes.py`·`test_issue60_opencode_v2.py`·`test_issue31_purge_residual.py` | 134 passed. |
| 전체 스위트 | **2080 passed / 20 skipped / 0 failed** (56분). |
| 실제 홈 사이드카 (`ls` 만) | MAM 이 남기거나 지운 것은 없다. 아래 참고. |
**leftover·walonly 가 Linux 에서 맞는지**
- 테스트 픽스처는 쓰는 연결이 열린 동안 `db`·`-wal`(·`-shm`) 을 복사해 상태를 만들고, 조회 전에 폴더 목록이 그 상태인지 먼저 단언한다. Linux 가 닫을 때 사이드카를 지워서 우연히 통과한 것이 아니다.
- 임시 DB 로 따로 확인했다. 네 상태(clean·leftover·walonly·writer) 모두 `_ro_connect` 로 여닫기를 여러 번 반복했다.
- 파일이 생기거나 지워지지 않았다. leftover 에서 마지막 연결이 닫혀도 `-wal`·`-shm` 이 남는다.
- 본 DB 와 `-wal` 은 바이트 단위로 그대로다. checkpoint 가 일어나지 않았다.
- leftover·writer 에서는 `-shm` 의 내용만 바뀐다. 읽는 쪽이 wal-index 에 read mark 를 쓰는 SQLite 의 정상 동작이고, 크기와 파일 목록은 그대로다.
- walonly 는 임시 사본으로 읽는다. 원본 폴더는 바이트까지 그대로이고, 임시 폴더도 남지 않았다.
**#28 이 함께 풀렸다**
- 지금까지 Linux 에서 늘 실패하던 `tests/test_issue10_13_purge.py` 의 agy 12건이 이번에는 모두 통과했다.
- 원인이 agy `verify_artifact` 의 읽기-쓰기 열기(닫을 때 Linux SQLite 가 픽스처의 `-wal`/`-shm` 을 지움)였는데, v4.9.8 에서 이 열기가 `_ro_connect` 로 바뀌었다. #28 은 닫아도 될 것 같다.
**실제 홈 사이드카 전후 비교** (`~/.gemini/antigravity-cli/conversations`·`~/.hermes`·`~/.codex`, `ls` 만)
- agy: 대화 1개의 `-wal`/`-shm` 쌍이 그대로 남았다. hermes: 전후 모두 없음.
- codex: 6쌍 중 4쌍(`goals_1`·`memories_1`·`state_5`·`thread_history_1`)이 스위트 도중 사라졌다. `logs_2`·`queue_1` 은 그대로다.
- 그 시각에 돈 codex 프로세스: codex app-server 데몬 2개와 code-mode host(며칠째 실행 중), 리뷰어로 띄워 둔 codex TUI 1개.
- MAM 이 지운 것으로 보지 않는다.
- `state_5`·`thread_history_1` 의 본 DB 수정 시각이 스위트 도중이다. checkpoint 가 본 DB 를 썼다는 뜻인데, `_ro_connect` 의 연결로는 쓸 수 없다.
- `goals_1`·`memories_1` 은 본 DB 수정 시각이 며칠 전 그대로라, 빈 WAL 을 가진 쓰기 연결이 닫히며 지운 모양이다.
- 그 시각에 MAM 모니터·reconcile 데몬은 돌지 않았고, 실제 codex 바이너리나 실제 홈을 쓰는 테스트도 없다.
- 즉 codex 자신의 쓰기 연결이 닫히며 Linux SQLite 가 정리한 것으로 본다.
**수정:** 필요 없다. `fix/issue-64-linux` 브랜치와 PR 은 만들지 않았다.
**체크리스트**
- [x] `test_issue64_ro_connect.py` 전체 통과 (leftover·walonly 폴더 목록 비교 포함)
- [x] 전체 스위트 새 실패 없음 (#28 의 12건도 통과)
- [x] `test_issue60_linux_fixes.py`·`test_issue60_opencode_v2.py` 통과
- [x] 실제 홈 사이드카 전후 비교
Linux 확인 결과를 확인했다. macOS·Linux 모두 완료 조건을 만족하므로 닫는다.
test_issue64_ro_connect.py 43개와 관련 묶음이 통과했다. 전체 스위트도 새 실패 없이 통과했다.
leftover·walonly 상태가 Linux 에서 우연히 통과한 것이 아님을 확인했다. 픽스처가 조회 전에 폴더 상태를 먼저 단언하고, 임시 DB 로 여닫기를 반복해도 파일 목록이 그대로였다.
남은 변화는 -shm 내용(read mark)뿐이다. 이는 v4.9.8 에 적어 둔 알려진 비차단 항목과 같다.
codex 사이드카가 사라진 것은 codex 자신의 쓰기 연결이 닫히며 정리한 것으로 본다. macOS 에서도 같은 현상이 보였다. 근거는 본 DB 의 수정 시각이 바뀐 점과 그 시각에 MAM 데몬이 없었던 점이다.
이후 v4.9.9(#40, PR #67)에서 agy 의 다른 작업 공간 ID 등록도 고쳐졌다. 그래서 v4.9.8 의 알려진 비차단 항목 중 "drift C(agy)가 다른 작업 공간의 대화를 후보로 받는다"는 해소됐다. v4.9.9 의 Linux 확인은 #40 에서 한다.
Linux 확인 결과를 확인했다. macOS·Linux 모두 완료 조건을 만족하므로 닫는다.
- `test_issue64_ro_connect.py` 43개와 관련 묶음이 통과했다. 전체 스위트도 새 실패 없이 통과했다.
- leftover·walonly 상태가 Linux 에서 우연히 통과한 것이 아님을 확인했다. 픽스처가 조회 전에 폴더 상태를 먼저 단언하고, 임시 DB 로 여닫기를 반복해도 파일 목록이 그대로였다.
- 남은 변화는 `-shm` 내용(read mark)뿐이다. 이는 v4.9.8 에 적어 둔 알려진 비차단 항목과 같다.
- codex 사이드카가 사라진 것은 codex 자신의 쓰기 연결이 닫히며 정리한 것으로 본다. macOS 에서도 같은 현상이 보였다. 근거는 본 DB 의 수정 시각이 바뀐 점과 그 시각에 MAM 데몬이 없었던 점이다.
- 이후 v4.9.9(#40, PR #67)에서 agy 의 다른 작업 공간 ID 등록도 고쳐졌다. 그래서 v4.9.8 의 알려진 비차단 항목 중 "drift C(agy)가 다른 작업 공간의 대화를 후보로 받는다"는 해소됐다. v4.9.9 의 Linux 확인은 #40 에서 한다.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
증상
MAM 은 에이전트의 대화 DB(SQLite)를 조회만 할 때도 쓰기 가능 모드(
sqlite3.connect(path))로 엽니다. 이렇게 열면 조회만 해도 에이전트 DB 옆의 파일이 바뀝니다.-wal·-shm을 만들고 그대로 남깁니다.-wal·-shm을 지웁니다. 에이전트가 쓰는 중이면 그 에이전트의 파일을 건드리는 셈입니다.opencode 는 v4.9.7(PR #62, Issue #60)에서 읽기 전용 열기
_ro_connect로 바꿨습니다. agy·codex·hermes 는 아직 그대로입니다.관련 관측 (원인 미확정)
v4.9.7 리뷰 중 macOS 전체 스위트에서 Issue #55 의 홈 가드가 오류를 냈습니다. 다른 워크스페이스의 agy 대화 DB 옆에
.db-wal·.db-shm이 새로 생겼고, 확인 시점에 그 DB 를 잡고 있는 프로세스는 없었습니다.대상 (조회 전용인데 쓰기 가능으로 여는 곳)
lib_py/agents/adapters/agy.py(verify,SELECT count(*) FROM steps)lib_py/agents/adapters/codex.py(_find_rollout_via_db,discover)multi-agent-mux-status/scripts/status.sh(codex 분기 2곳)multi-agent-mux-monitor/scripts/reconcile.sh(codex drift)lib_py/agents/adapters/hermes.py(verify_artifact,discover)multi-agent-mux-status/scripts/status.sh(hermes 분기 2곳)multi-agent-mux-monitor/scripts/reconcile.sh(hermes drift)대상이 아닌 곳
DELETE, opencode purge 의 옛 행 정리가 여기에 해당합니다.agent-sessions.db,atomic_yaml·state·verify_session·loop runner)도 대상이 아닙니다.제안
_ro_connect(사이드카 상태에 따라mode=ro/mode=ro&immutable=1/-shm없는-wal은 임시 복사본)를 공용 helper 로 옮깁니다. 예:lib_py/agents/base.py.-shm없는-wal, 쓰는 중)에서 조회 결과가 맞고 디렉터리 목록이 바뀌지 않는지 확인합니다. macOS 의 persistent WAL 을 고려해, clean 상태는 테스트가 사이드카를 지워서 만듭니다.참고
tests/test_issue60_linux_fixes.py)macOS 처리 결과 (PR #65, v4.9.8 병합)
원인
reconcile.shdrift C(agy)는 고정되지 않은 agy 행이 있으면 호스트 공용 대화 폴더의 모든*.db를 후보로 본다.AgyAgentAdapter.verify_artifact가SELECT count(*) FROM steps를 쓰기 가능 연결로 실행했다.-wal·-shm을 남긴다. 그래서 다른 작업 공간의 대화 DB 옆에 사이드카가 생겼다.status.sh·create_session.sh도 reconcile 을 부르므로 같은 경로를 탄다.수정
_ro_connect를lib_py/agents/base.py로 옮겼다. opencode 동작은 그대로다.verify_artifact_find_rollout_via_db·discoververify_artifact·discoverstatus.shhermes·codexreconcile.shdrift C hermes·codexdb_rows_naming기본 열기검증 (macOS, Python 3.9.6)
tests/test_issue64_ro_connect.py43개. base(v4.9.7)에서는 23개가 실패한다.Linux 확인 요청
Linux 의 SQLite 는 닫을 때
-wal·-shm을 지운다. 그래서 macOS 와 결과가 다를 수 있는 곳만 확인하면 된다. 실제 에이전트 홈의 DB 는 열지 말고, 임시 HOME 에서만 확인한다.pytest tests/test_issue64_ro_connect.py가 모두 통과한다. 특히leftover(사이드카 쌍만 남음)·walonly상태의 폴더 목록 비교가 맞는지 본다.test_issue10_13_purge.pyagy 실패(#28)는 제외한다.test_issue60_linux_fixes.py·test_issue60_opencode_v2.py가 그대로 통과한다. opencode 가 공용_ro_connect를 import 한다.~/.gemini/antigravity-cli/conversations·~/.hermes·~/.codex의-wal/-shm목록을ls로 비교한다.남은 비차단 (별도 처리 후보)
last_conversations.json이 다른 작업 공간에 기록한 대화도 후보로 받아 고정할 수 있다(기존 동작). 새 테스트test_unpinned_agy_reconcile_…가 이 동작을 단언하므로, 고칠 때 함께 바꾼다.mode=ro로 읽는다.Linux 확인 결과 (v4.9.8,
ff8b381)환경: Ubuntu 26.04.1 LTS (kernel 7.0), Python 3.14.7, SQLite 3.53.4.
XDG_*를 비우고 돌렸다.tests/test_issue64_ro_connect.pytest_issue60_linux_fixes.py·test_issue60_opencode_v2.py·test_issue31_purge_residual.pyls만)leftover·walonly 가 Linux 에서 맞는지
db·-wal(·-shm) 을 복사해 상태를 만들고, 조회 전에 폴더 목록이 그 상태인지 먼저 단언한다. Linux 가 닫을 때 사이드카를 지워서 우연히 통과한 것이 아니다._ro_connect로 여닫기를 여러 번 반복했다.-wal·-shm이 남는다.-wal은 바이트 단위로 그대로다. checkpoint 가 일어나지 않았다.-shm의 내용만 바뀐다. 읽는 쪽이 wal-index 에 read mark 를 쓰는 SQLite 의 정상 동작이고, 크기와 파일 목록은 그대로다.#28 이 함께 풀렸다
tests/test_issue10_13_purge.py의 agy 12건이 이번에는 모두 통과했다.verify_artifact의 읽기-쓰기 열기(닫을 때 Linux SQLite 가 픽스처의-wal/-shm을 지움)였는데, v4.9.8 에서 이 열기가_ro_connect로 바뀌었다. #28 은 닫아도 될 것 같다.실제 홈 사이드카 전후 비교 (
~/.gemini/antigravity-cli/conversations·~/.hermes·~/.codex,ls만)-wal/-shm쌍이 그대로 남았다. hermes: 전후 모두 없음.goals_1·memories_1·state_5·thread_history_1)이 스위트 도중 사라졌다.logs_2·queue_1은 그대로다.state_5·thread_history_1의 본 DB 수정 시각이 스위트 도중이다. checkpoint 가 본 DB 를 썼다는 뜻인데,_ro_connect의 연결로는 쓸 수 없다.goals_1·memories_1은 본 DB 수정 시각이 며칠 전 그대로라, 빈 WAL 을 가진 쓰기 연결이 닫히며 지운 모양이다.수정: 필요 없다.
fix/issue-64-linux브랜치와 PR 은 만들지 않았다.체크리스트
test_issue64_ro_connect.py전체 통과 (leftover·walonly 폴더 목록 비교 포함)test_issue60_linux_fixes.py·test_issue60_opencode_v2.py통과Linux 확인 결과를 확인했다. macOS·Linux 모두 완료 조건을 만족하므로 닫는다.
test_issue64_ro_connect.py43개와 관련 묶음이 통과했다. 전체 스위트도 새 실패 없이 통과했다.-shm내용(read mark)뿐이다. 이는 v4.9.8 에 적어 둔 알려진 비차단 항목과 같다.