fix(macos): let a scan walk past a page whose pager declines to read by JeanExtreme002 · Pull Request #88 · JeanExtreme002/PyMemoryEditor

JeanExtreme002 · 2026-08-28T14:06:25Z

Why is this PR necessary, what does it do?

A scan of a live process on macOS aborts part-way through with

MachReadError: mach_vm_read_overwrite failed: (os/kern) memory error (kr=10)

throwing away the rest of the address space. The addresses found before the bad
page survive in the results table, so the app ends up in a confusing half-state:
a populated result list and an error dialog.

kr=10 is KERN_MEMORY_ERROR, and mach/kern_return.h documents it as:

During a page fault, the memory object indicated that the data could not be
returned. This failure may be temporary; future attempts to access this
same data may succeed, as defined by the memory object.

— in deliberate contrast with KERN_MEMORY_FAILURE (9) immediately above it in
that header, whose comment ends "This failure is permanent."

So by the kernel's own definition it belongs in _PAGE_GONE_KRS alongside the
three codes already there. It was simply missed — it wasn't even defined in
macos/types.py.

Nothing else needed changing. The tolerance machinery already exists and is
already wired into all three entry points (search_addresses_by_value,
search_addresses_by_pattern, search_values_by_addresses all pass
transient_error_check=_is_transient). The code was just on the wrong side of
the line _is_transient draws, so iter_search_results and
iter_pattern_results took their raise branch and killed the scan.

Why it shows up on pattern scans first

KERN_MEMORY_ERROR comes from a pager declining to produce a page, so it
turns up on file-backed read-only mappings — code segments, dylibs, the dyld
shared cache. A pattern scan deliberately ignores writeable_only (an AOB
signature normally lives in code), so it walks those; a value scan with the
app's default "writable regions only" never goes near them. Measured on a
trivial Python process:

regions total : 148
pattern scan (regex / AOB) : 135 <- ignores writeable_only
value scan (writable only) : 58 <- the app's default
read-only regions a default value scan never walks: 77

Turning "writable regions only" off reproduces it with any value type, which is
how this was confirmed rather than assumed.

Checklist (complete all items):

Added tests as necessary.
There is no breaking change for existing features.

References:

No references to be shared.

Notes:

The new test pins both sides of the classification: the four codes a scan may
walk past, and the ones that must still reach the caller (a protection failure
or the permanent KERN_MEMORY_FAILURE) so this doesn't drift into swallowing
real permission problems.

On the machine this was found on, the entire tests/memory and tests/scan
suite failed this way — 15 tests, all with kr=10. They pass now. Worth noting
that they pass legitimately: those tests plant a value or a byte marker and
assert it is found (assert address in hits), so the scans are completing and
matching, not quietly finding nothing.

Linux is unaffected — it has its own _is_transient over a separate errno set.

A scan of a live process aborted with MachReadError: mach_vm_read_overwrite failed: (os/kern) memory error (kr=10) part-way through, discarding the rest of the address space. kr=10 is KERN_MEMORY_ERROR, and mach/kern_return.h documents it as "During a page fault, the memory object indicated that the data could not be returned. This failure may be temporary; future attempts to access this same data may succeed" — in deliberate contrast with KERN_MEMORY_FAILURE (9) directly above it, whose comment ends "This failure is permanent." So by the kernel's own definition it belongs in _PAGE_GONE_KRS beside the three codes already there; it was simply missed, and wasn't even defined in types.py. The tolerance machinery was already in place and already wired into all three entry points — the code was just on the wrong side of the line _is_transient draws, so iter_search_results and iter_pattern_results re-raised it and killed the scan. It surfaces on file-backed read-only mappings — code segments, dylibs, the dyld shared cache — which is why a pattern scan hit it first: it deliberately ignores writeable_only (an AOB signature is normally in code), so it walks 2.3x the regions a default value scan does on a trivial process. Turning "writable regions only" off reproduces it with any value type. On this machine the whole memory/scan suite failed this way; it now passes, and those tests plant a value and assert they find it, so the scans are completing rather than quietly matching nothing.

…ther Self-review follow-ups, no behaviour change. The comment justifying the fix leaned on KERN_MEMORY_FAILURE (9) as the contrast case, but that constant wasn't in types.py — leaving a gap in the sequence (2, 4, 5, 8, 10) and a comment pointing at something the file didn't contain. The module's existing convention is to define the codes it talks about even when only prose refers to them (KERN_FAILURE is already there on those terms), so the two neighbours are now defined together with the header text that separates them. The test was declaring its own copy of 9, which is the kind of local constant that drifts from the library it describes. The "must still propagate" case tested KERN_SUCCESS, a state no MachReadError can carry — MachPartialReadError is raised on success but passes KERN_INVALID_ADDRESS. Swapped for KERN_FAILURE, which is what task_for_pid returns without the debugger entitlement and is a real error this must never swallow.

JeanExtreme002 · 2026-08-28T14:06:25Z

Why is this PR necessary, what does it do?

A scan of a live process on macOS aborts part-way through with

MachReadError: mach_vm_read_overwrite failed: (os/kern) memory error (kr=10)

throwing away the rest of the address space. The addresses found before the bad
page survive in the results table, so the app ends up in a confusing half-state:
a populated result list and an error dialog.

kr=10 is KERN_MEMORY_ERROR, and mach/kern_return.h documents it as:

During a page fault, the memory object indicated that the data could not be
returned. This failure may be temporary; future attempts to access this
same data may succeed, as defined by the memory object.

— in deliberate contrast with KERN_MEMORY_FAILURE (9) immediately above it in
that header, whose comment ends "This failure is permanent."

So by the kernel's own definition it belongs in _PAGE_GONE_KRS alongside the
three codes already there. It was simply missed — it wasn't even defined in
macos/types.py.

Nothing else needed changing. The tolerance machinery already exists and is
already wired into all three entry points (search_addresses_by_value,
search_addresses_by_pattern, search_values_by_addresses all pass
transient_error_check=_is_transient). The code was just on the wrong side of
the line _is_transient draws, so iter_search_results and
iter_pattern_results took their raise branch and killed the scan.

Why it shows up on pattern scans first

KERN_MEMORY_ERROR comes from a pager declining to produce a page, so it
turns up on file-backed read-only mappings — code segments, dylibs, the dyld
shared cache. A pattern scan deliberately ignores writeable_only (an AOB
signature normally lives in code), so it walks those; a value scan with the
app's default "writable regions only" never goes near them. Measured on a
trivial Python process:

regions total : 148
pattern scan (regex / AOB) : 135 <- ignores writeable_only
value scan (writable only) : 58 <- the app's default
read-only regions a default value scan never walks: 77

Turning "writable regions only" off reproduces it with any value type, which is
how this was confirmed rather than assumed.

Checklist (complete all items):

Added tests as necessary.
There is no breaking change for existing features.

References:

No references to be shared.

Notes:

The new test pins both sides of the classification: the four codes a scan may
walk past, and the ones that must still reach the caller (a protection failure
or the permanent KERN_MEMORY_FAILURE) so this doesn't drift into swallowing
real permission problems.

On the machine this was found on, the entire tests/memory and tests/scan
suite failed this way — 15 tests, all with kr=10. They pass now. Worth noting
that they pass legitimately: those tests plant a value or a byte marker and
assert it is found (assert address in hits), so the scans are completing and
matching, not quietly finding nothing.

Linux is unaffected — it has its own _is_transient over a separate errno set.

A scan of a live process aborted with MachReadError: mach_vm_read_overwrite failed: (os/kern) memory error (kr=10) part-way through, discarding the rest of the address space. kr=10 is KERN_MEMORY_ERROR, and mach/kern_return.h documents it as "During a page fault, the memory object indicated that the data could not be returned. This failure may be temporary; future attempts to access this same data may succeed" — in deliberate contrast with KERN_MEMORY_FAILURE (9) directly above it, whose comment ends "This failure is permanent." So by the kernel's own definition it belongs in _PAGE_GONE_KRS beside the three codes already there; it was simply missed, and wasn't even defined in types.py. The tolerance machinery was already in place and already wired into all three entry points — the code was just on the wrong side of the line _is_transient draws, so iter_search_results and iter_pattern_results re-raised it and killed the scan. It surfaces on file-backed read-only mappings — code segments, dylibs, the dyld shared cache — which is why a pattern scan hit it first: it deliberately ignores writeable_only (an AOB signature is normally in code), so it walks 2.3x the regions a default value scan does on a trivial process. Turning "writable regions only" off reproduces it with any value type. On this machine the whole memory/scan suite failed this way; it now passes, and those tests plant a value and assert they find it, so the scans are completing rather than quietly matching nothing.

…ther Self-review follow-ups, no behaviour change. The comment justifying the fix leaned on KERN_MEMORY_FAILURE (9) as the contrast case, but that constant wasn't in types.py — leaving a gap in the sequence (2, 4, 5, 8, 10) and a comment pointing at something the file didn't contain. The module's existing convention is to define the codes it talks about even when only prose refers to them (KERN_FAILURE is already there on those terms), so the two neighbours are now defined together with the header text that separates them. The test was declaring its own copy of 9, which is the kind of local constant that drifts from the library it describes. The "must still propagate" case tested KERN_SUCCESS, a state no MachReadError can carry — MachPartialReadError is raised on success but passes KERN_INVALID_ADDRESS. Swapped for KERN_FAILURE, which is what task_for_pid returns without the debugger entitlement and is a real error this must never swallow.

JeanExtreme002 · 2026-08-28T14:06:25Z

Why is this PR necessary, what does it do?

A scan of a live process on macOS aborts part-way through with

MachReadError: mach_vm_read_overwrite failed: (os/kern) memory error (kr=10)

throwing away the rest of the address space. The addresses found before the bad
page survive in the results table, so the app ends up in a confusing half-state:
a populated result list and an error dialog.

kr=10 is KERN_MEMORY_ERROR, and mach/kern_return.h documents it as:

During a page fault, the memory object indicated that the data could not be
returned. This failure may be temporary; future attempts to access this
same data may succeed, as defined by the memory object.

— in deliberate contrast with KERN_MEMORY_FAILURE (9) immediately above it in
that header, whose comment ends "This failure is permanent."

So by the kernel's own definition it belongs in _PAGE_GONE_KRS alongside the
three codes already there. It was simply missed — it wasn't even defined in
macos/types.py.

Nothing else needed changing. The tolerance machinery already exists and is
already wired into all three entry points (search_addresses_by_value,
search_addresses_by_pattern, search_values_by_addresses all pass
transient_error_check=_is_transient). The code was just on the wrong side of
the line _is_transient draws, so iter_search_results and
iter_pattern_results took their raise branch and killed the scan.

Why it shows up on pattern scans first

KERN_MEMORY_ERROR comes from a pager declining to produce a page, so it
turns up on file-backed read-only mappings — code segments, dylibs, the dyld
shared cache. A pattern scan deliberately ignores writeable_only (an AOB
signature normally lives in code), so it walks those; a value scan with the
app's default "writable regions only" never goes near them. Measured on a
trivial Python process:

regions total : 148
pattern scan (regex / AOB) : 135 <- ignores writeable_only
value scan (writable only) : 58 <- the app's default
read-only regions a default value scan never walks: 77

Turning "writable regions only" off reproduces it with any value type, which is
how this was confirmed rather than assumed.

Checklist (complete all items):

Added tests as necessary.
There is no breaking change for existing features.

References:

No references to be shared.

Notes:

The new test pins both sides of the classification: the four codes a scan may
walk past, and the ones that must still reach the caller (a protection failure
or the permanent KERN_MEMORY_FAILURE) so this doesn't drift into swallowing
real permission problems.

On the machine this was found on, the entire tests/memory and tests/scan
suite failed this way — 15 tests, all with kr=10. They pass now. Worth noting
that they pass legitimately: those tests plant a value or a byte marker and
assert it is found (assert address in hits), so the scans are completing and
matching, not quietly finding nothing.

Linux is unaffected — it has its own _is_transient over a separate errno set.

A scan of a live process aborted with MachReadError: mach_vm_read_overwrite failed: (os/kern) memory error (kr=10) part-way through, discarding the rest of the address space. kr=10 is KERN_MEMORY_ERROR, and mach/kern_return.h documents it as "During a page fault, the memory object indicated that the data could not be returned. This failure may be temporary; future attempts to access this same data may succeed" — in deliberate contrast with KERN_MEMORY_FAILURE (9) directly above it, whose comment ends "This failure is permanent." So by the kernel's own definition it belongs in _PAGE_GONE_KRS beside the three codes already there; it was simply missed, and wasn't even defined in types.py. The tolerance machinery was already in place and already wired into all three entry points — the code was just on the wrong side of the line _is_transient draws, so iter_search_results and iter_pattern_results re-raised it and killed the scan. It surfaces on file-backed read-only mappings — code segments, dylibs, the dyld shared cache — which is why a pattern scan hit it first: it deliberately ignores writeable_only (an AOB signature is normally in code), so it walks 2.3x the regions a default value scan does on a trivial process. Turning "writable regions only" off reproduces it with any value type. On this machine the whole memory/scan suite failed this way; it now passes, and those tests plant a value and assert they find it, so the scans are completing rather than quietly matching nothing.

…ther Self-review follow-ups, no behaviour change. The comment justifying the fix leaned on KERN_MEMORY_FAILURE (9) as the contrast case, but that constant wasn't in types.py — leaving a gap in the sequence (2, 4, 5, 8, 10) and a comment pointing at something the file didn't contain. The module's existing convention is to define the codes it talks about even when only prose refers to them (KERN_FAILURE is already there on those terms), so the two neighbours are now defined together with the header text that separates them. The test was declaring its own copy of 9, which is the kind of local constant that drifts from the library it describes. The "must still propagate" case tested KERN_SUCCESS, a state no MachReadError can carry — MachPartialReadError is raised on success but passes KERN_INVALID_ADDRESS. Swapped for KERN_FAILURE, which is what task_for_pid returns without the debugger entitlement and is a real error this must never swallow.

JeanExtreme002 · 2026-08-28T14:06:25Z

Why is this PR necessary, what does it do?

A scan of a live process on macOS aborts part-way through with

MachReadError: mach_vm_read_overwrite failed: (os/kern) memory error (kr=10)

throwing away the rest of the address space. The addresses found before the bad
page survive in the results table, so the app ends up in a confusing half-state:
a populated result list and an error dialog.

kr=10 is KERN_MEMORY_ERROR, and mach/kern_return.h documents it as:

During a page fault, the memory object indicated that the data could not be
returned. This failure may be temporary; future attempts to access this
same data may succeed, as defined by the memory object.

— in deliberate contrast with KERN_MEMORY_FAILURE (9) immediately above it in
that header, whose comment ends "This failure is permanent."

So by the kernel's own definition it belongs in _PAGE_GONE_KRS alongside the
three codes already there. It was simply missed — it wasn't even defined in
macos/types.py.

Nothing else needed changing. The tolerance machinery already exists and is
already wired into all three entry points (search_addresses_by_value,
search_addresses_by_pattern, search_values_by_addresses all pass
transient_error_check=_is_transient). The code was just on the wrong side of
the line _is_transient draws, so iter_search_results and
iter_pattern_results took their raise branch and killed the scan.

Why it shows up on pattern scans first

KERN_MEMORY_ERROR comes from a pager declining to produce a page, so it
turns up on file-backed read-only mappings — code segments, dylibs, the dyld
shared cache. A pattern scan deliberately ignores writeable_only (an AOB
signature normally lives in code), so it walks those; a value scan with the
app's default "writable regions only" never goes near them. Measured on a
trivial Python process:

regions total : 148
pattern scan (regex / AOB) : 135 <- ignores writeable_only
value scan (writable only) : 58 <- the app's default
read-only regions a default value scan never walks: 77

Turning "writable regions only" off reproduces it with any value type, which is
how this was confirmed rather than assumed.

Checklist (complete all items):

Added tests as necessary.
There is no breaking change for existing features.

References:

No references to be shared.

Notes:

The new test pins both sides of the classification: the four codes a scan may
walk past, and the ones that must still reach the caller (a protection failure
or the permanent KERN_MEMORY_FAILURE) so this doesn't drift into swallowing
real permission problems.

On the machine this was found on, the entire tests/memory and tests/scan
suite failed this way — 15 tests, all with kr=10. They pass now. Worth noting
that they pass legitimately: those tests plant a value or a byte marker and
assert it is found (assert address in hits), so the scans are completing and
matching, not quietly finding nothing.

Linux is unaffected — it has its own _is_transient over a separate errno set.

A scan of a live process aborted with MachReadError: mach_vm_read_overwrite failed: (os/kern) memory error (kr=10) part-way through, discarding the rest of the address space. kr=10 is KERN_MEMORY_ERROR, and mach/kern_return.h documents it as "During a page fault, the memory object indicated that the data could not be returned. This failure may be temporary; future attempts to access this same data may succeed" — in deliberate contrast with KERN_MEMORY_FAILURE (9) directly above it, whose comment ends "This failure is permanent." So by the kernel's own definition it belongs in _PAGE_GONE_KRS beside the three codes already there; it was simply missed, and wasn't even defined in types.py. The tolerance machinery was already in place and already wired into all three entry points — the code was just on the wrong side of the line _is_transient draws, so iter_search_results and iter_pattern_results re-raised it and killed the scan. It surfaces on file-backed read-only mappings — code segments, dylibs, the dyld shared cache — which is why a pattern scan hit it first: it deliberately ignores writeable_only (an AOB signature is normally in code), so it walks 2.3x the regions a default value scan does on a trivial process. Turning "writable regions only" off reproduces it with any value type. On this machine the whole memory/scan suite failed this way; it now passes, and those tests plant a value and assert they find it, so the scans are completing rather than quietly matching nothing.

…ther Self-review follow-ups, no behaviour change. The comment justifying the fix leaned on KERN_MEMORY_FAILURE (9) as the contrast case, but that constant wasn't in types.py — leaving a gap in the sequence (2, 4, 5, 8, 10) and a comment pointing at something the file didn't contain. The module's existing convention is to define the codes it talks about even when only prose refers to them (KERN_FAILURE is already there on those terms), so the two neighbours are now defined together with the header text that separates them. The test was declaring its own copy of 9, which is the kind of local constant that drifts from the library it describes. The "must still propagate" case tested KERN_SUCCESS, a state no MachReadError can carry — MachPartialReadError is raised on success but passes KERN_INVALID_ADDRESS. Swapped for KERN_FAILURE, which is what task_for_pid returns without the debugger entitlement and is a real error this must never swallow.

JeanExtreme002 · 2026-08-28T14:06:25Z

Why is this PR necessary, what does it do?

A scan of a live process on macOS aborts part-way through with

MachReadError: mach_vm_read_overwrite failed: (os/kern) memory error (kr=10)

throwing away the rest of the address space. The addresses found before the bad
page survive in the results table, so the app ends up in a confusing half-state:
a populated result list and an error dialog.

kr=10 is KERN_MEMORY_ERROR, and mach/kern_return.h documents it as:

During a page fault, the memory object indicated that the data could not be
returned. This failure may be temporary; future attempts to access this
same data may succeed, as defined by the memory object.

— in deliberate contrast with KERN_MEMORY_FAILURE (9) immediately above it in
that header, whose comment ends "This failure is permanent."

So by the kernel's own definition it belongs in _PAGE_GONE_KRS alongside the
three codes already there. It was simply missed — it wasn't even defined in
macos/types.py.

Nothing else needed changing. The tolerance machinery already exists and is
already wired into all three entry points (search_addresses_by_value,
search_addresses_by_pattern, search_values_by_addresses all pass
transient_error_check=_is_transient). The code was just on the wrong side of
the line _is_transient draws, so iter_search_results and
iter_pattern_results took their raise branch and killed the scan.

Why it shows up on pattern scans first

KERN_MEMORY_ERROR comes from a pager declining to produce a page, so it
turns up on file-backed read-only mappings — code segments, dylibs, the dyld
shared cache. A pattern scan deliberately ignores writeable_only (an AOB
signature normally lives in code), so it walks those; a value scan with the
app's default "writable regions only" never goes near them. Measured on a
trivial Python process:

regions total : 148
pattern scan (regex / AOB) : 135 <- ignores writeable_only
value scan (writable only) : 58 <- the app's default
read-only regions a default value scan never walks: 77

Turning "writable regions only" off reproduces it with any value type, which is
how this was confirmed rather than assumed.

Checklist (complete all items):

Added tests as necessary.
There is no breaking change for existing features.

References:

No references to be shared.

Notes:

The new test pins both sides of the classification: the four codes a scan may
walk past, and the ones that must still reach the caller (a protection failure
or the permanent KERN_MEMORY_FAILURE) so this doesn't drift into swallowing
real permission problems.

On the machine this was found on, the entire tests/memory and tests/scan
suite failed this way — 15 tests, all with kr=10. They pass now. Worth noting
that they pass legitimately: those tests plant a value or a byte marker and
assert it is found (assert address in hits), so the scans are completing and
matching, not quietly finding nothing.

Linux is unaffected — it has its own _is_transient over a separate errno set.

A scan of a live process aborted with MachReadError: mach_vm_read_overwrite failed: (os/kern) memory error (kr=10) part-way through, discarding the rest of the address space. kr=10 is KERN_MEMORY_ERROR, and mach/kern_return.h documents it as "During a page fault, the memory object indicated that the data could not be returned. This failure may be temporary; future attempts to access this same data may succeed" — in deliberate contrast with KERN_MEMORY_FAILURE (9) directly above it, whose comment ends "This failure is permanent." So by the kernel's own definition it belongs in _PAGE_GONE_KRS beside the three codes already there; it was simply missed, and wasn't even defined in types.py. The tolerance machinery was already in place and already wired into all three entry points — the code was just on the wrong side of the line _is_transient draws, so iter_search_results and iter_pattern_results re-raised it and killed the scan. It surfaces on file-backed read-only mappings — code segments, dylibs, the dyld shared cache — which is why a pattern scan hit it first: it deliberately ignores writeable_only (an AOB signature is normally in code), so it walks 2.3x the regions a default value scan does on a trivial process. Turning "writable regions only" off reproduces it with any value type. On this machine the whole memory/scan suite failed this way; it now passes, and those tests plant a value and assert they find it, so the scans are completing rather than quietly matching nothing.

…ther Self-review follow-ups, no behaviour change. The comment justifying the fix leaned on KERN_MEMORY_FAILURE (9) as the contrast case, but that constant wasn't in types.py — leaving a gap in the sequence (2, 4, 5, 8, 10) and a comment pointing at something the file didn't contain. The module's existing convention is to define the codes it talks about even when only prose refers to them (KERN_FAILURE is already there on those terms), so the two neighbours are now defined together with the header text that separates them. The test was declaring its own copy of 9, which is the kind of local constant that drifts from the library it describes. The "must still propagate" case tested KERN_SUCCESS, a state no MachReadError can carry — MachPartialReadError is raised on success but passes KERN_INVALID_ADDRESS. Swapped for KERN_FAILURE, which is what task_for_pid returns without the debugger entitlement and is a real error this must never swallow.

JeanExtreme002 · 2026-08-28T14:06:25Z

Why is this PR necessary, what does it do?

A scan of a live process on macOS aborts part-way through with

MachReadError: mach_vm_read_overwrite failed: (os/kern) memory error (kr=10)

throwing away the rest of the address space. The addresses found before the bad
page survive in the results table, so the app ends up in a confusing half-state:
a populated result list and an error dialog.

kr=10 is KERN_MEMORY_ERROR, and mach/kern_return.h documents it as:

During a page fault, the memory object indicated that the data could not be
returned. This failure may be temporary; future attempts to access this
same data may succeed, as defined by the memory object.

— in deliberate contrast with KERN_MEMORY_FAILURE (9) immediately above it in
that header, whose comment ends "This failure is permanent."

So by the kernel's own definition it belongs in _PAGE_GONE_KRS alongside the
three codes already there. It was simply missed — it wasn't even defined in
macos/types.py.

Nothing else needed changing. The tolerance machinery already exists and is
already wired into all three entry points (search_addresses_by_value,
search_addresses_by_pattern, search_values_by_addresses all pass
transient_error_check=_is_transient). The code was just on the wrong side of
the line _is_transient draws, so iter_search_results and
iter_pattern_results took their raise branch and killed the scan.

Why it shows up on pattern scans first

KERN_MEMORY_ERROR comes from a pager declining to produce a page, so it
turns up on file-backed read-only mappings — code segments, dylibs, the dyld
shared cache. A pattern scan deliberately ignores writeable_only (an AOB
signature normally lives in code), so it walks those; a value scan with the
app's default "writable regions only" never goes near them. Measured on a
trivial Python process:

regions total : 148
pattern scan (regex / AOB) : 135 <- ignores writeable_only
value scan (writable only) : 58 <- the app's default
read-only regions a default value scan never walks: 77

Turning "writable regions only" off reproduces it with any value type, which is
how this was confirmed rather than assumed.

Checklist (complete all items):

Added tests as necessary.
There is no breaking change for existing features.

References:

No references to be shared.

Notes:

The new test pins both sides of the classification: the four codes a scan may
walk past, and the ones that must still reach the caller (a protection failure
or the permanent KERN_MEMORY_FAILURE) so this doesn't drift into swallowing
real permission problems.

On the machine this was found on, the entire tests/memory and tests/scan
suite failed this way — 15 tests, all with kr=10. They pass now. Worth noting
that they pass legitimately: those tests plant a value or a byte marker and
assert it is found (assert address in hits), so the scans are completing and
matching, not quietly finding nothing.

Linux is unaffected — it has its own _is_transient over a separate errno set.

A scan of a live process aborted with MachReadError: mach_vm_read_overwrite failed: (os/kern) memory error (kr=10) part-way through, discarding the rest of the address space. kr=10 is KERN_MEMORY_ERROR, and mach/kern_return.h documents it as "During a page fault, the memory object indicated that the data could not be returned. This failure may be temporary; future attempts to access this same data may succeed" — in deliberate contrast with KERN_MEMORY_FAILURE (9) directly above it, whose comment ends "This failure is permanent." So by the kernel's own definition it belongs in _PAGE_GONE_KRS beside the three codes already there; it was simply missed, and wasn't even defined in types.py. The tolerance machinery was already in place and already wired into all three entry points — the code was just on the wrong side of the line _is_transient draws, so iter_search_results and iter_pattern_results re-raised it and killed the scan. It surfaces on file-backed read-only mappings — code segments, dylibs, the dyld shared cache — which is why a pattern scan hit it first: it deliberately ignores writeable_only (an AOB signature is normally in code), so it walks 2.3x the regions a default value scan does on a trivial process. Turning "writable regions only" off reproduces it with any value type. On this machine the whole memory/scan suite failed this way; it now passes, and those tests plant a value and assert they find it, so the scans are completing rather than quietly matching nothing.

…ther Self-review follow-ups, no behaviour change. The comment justifying the fix leaned on KERN_MEMORY_FAILURE (9) as the contrast case, but that constant wasn't in types.py — leaving a gap in the sequence (2, 4, 5, 8, 10) and a comment pointing at something the file didn't contain. The module's existing convention is to define the codes it talks about even when only prose refers to them (KERN_FAILURE is already there on those terms), so the two neighbours are now defined together with the header text that separates them. The test was declaring its own copy of 9, which is the kind of local constant that drifts from the library it describes. The "must still propagate" case tested KERN_SUCCESS, a state no MachReadError can carry — MachPartialReadError is raised on success but passes KERN_INVALID_ADDRESS. Swapped for KERN_FAILURE, which is what task_for_pid returns without the debugger entitlement and is a real error this must never swallow.

JeanExtreme002 · 2026-08-28T14:06:25Z

Why is this PR necessary, what does it do?

A scan of a live process on macOS aborts part-way through with

MachReadError: mach_vm_read_overwrite failed: (os/kern) memory error (kr=10)

throwing away the rest of the address space. The addresses found before the bad
page survive in the results table, so the app ends up in a confusing half-state:
a populated result list and an error dialog.

kr=10 is KERN_MEMORY_ERROR, and mach/kern_return.h documents it as:

During a page fault, the memory object indicated that the data could not be
returned. This failure may be temporary; future attempts to access this
same data may succeed, as defined by the memory object.

— in deliberate contrast with KERN_MEMORY_FAILURE (9) immediately above it in
that header, whose comment ends "This failure is permanent."

So by the kernel's own definition it belongs in _PAGE_GONE_KRS alongside the
three codes already there. It was simply missed — it wasn't even defined in
macos/types.py.

Nothing else needed changing. The tolerance machinery already exists and is
already wired into all three entry points (search_addresses_by_value,
search_addresses_by_pattern, search_values_by_addresses all pass
transient_error_check=_is_transient). The code was just on the wrong side of
the line _is_transient draws, so iter_search_results and
iter_pattern_results took their raise branch and killed the scan.

Why it shows up on pattern scans first

KERN_MEMORY_ERROR comes from a pager declining to produce a page, so it
turns up on file-backed read-only mappings — code segments, dylibs, the dyld
shared cache. A pattern scan deliberately ignores writeable_only (an AOB
signature normally lives in code), so it walks those; a value scan with the
app's default "writable regions only" never goes near them. Measured on a
trivial Python process:

regions total : 148
pattern scan (regex / AOB) : 135 <- ignores writeable_only
value scan (writable only) : 58 <- the app's default
read-only regions a default value scan never walks: 77

Turning "writable regions only" off reproduces it with any value type, which is
how this was confirmed rather than assumed.

Checklist (complete all items):

Added tests as necessary.
There is no breaking change for existing features.

References:

No references to be shared.

Notes:

The new test pins both sides of the classification: the four codes a scan may
walk past, and the ones that must still reach the caller (a protection failure
or the permanent KERN_MEMORY_FAILURE) so this doesn't drift into swallowing
real permission problems.

On the machine this was found on, the entire tests/memory and tests/scan
suite failed this way — 15 tests, all with kr=10. They pass now. Worth noting
that they pass legitimately: those tests plant a value or a byte marker and
assert it is found (assert address in hits), so the scans are completing and
matching, not quietly finding nothing.

Linux is unaffected — it has its own _is_transient over a separate errno set.

A scan of a live process aborted with MachReadError: mach_vm_read_overwrite failed: (os/kern) memory error (kr=10) part-way through, discarding the rest of the address space. kr=10 is KERN_MEMORY_ERROR, and mach/kern_return.h documents it as "During a page fault, the memory object indicated that the data could not be returned. This failure may be temporary; future attempts to access this same data may succeed" — in deliberate contrast with KERN_MEMORY_FAILURE (9) directly above it, whose comment ends "This failure is permanent." So by the kernel's own definition it belongs in _PAGE_GONE_KRS beside the three codes already there; it was simply missed, and wasn't even defined in types.py. The tolerance machinery was already in place and already wired into all three entry points — the code was just on the wrong side of the line _is_transient draws, so iter_search_results and iter_pattern_results re-raised it and killed the scan. It surfaces on file-backed read-only mappings — code segments, dylibs, the dyld shared cache — which is why a pattern scan hit it first: it deliberately ignores writeable_only (an AOB signature is normally in code), so it walks 2.3x the regions a default value scan does on a trivial process. Turning "writable regions only" off reproduces it with any value type. On this machine the whole memory/scan suite failed this way; it now passes, and those tests plant a value and assert they find it, so the scans are completing rather than quietly matching nothing.

…ther Self-review follow-ups, no behaviour change. The comment justifying the fix leaned on KERN_MEMORY_FAILURE (9) as the contrast case, but that constant wasn't in types.py — leaving a gap in the sequence (2, 4, 5, 8, 10) and a comment pointing at something the file didn't contain. The module's existing convention is to define the codes it talks about even when only prose refers to them (KERN_FAILURE is already there on those terms), so the two neighbours are now defined together with the header text that separates them. The test was declaring its own copy of 9, which is the kind of local constant that drifts from the library it describes. The "must still propagate" case tested KERN_SUCCESS, a state no MachReadError can carry — MachPartialReadError is raised on success but passes KERN_INVALID_ADDRESS. Swapped for KERN_FAILURE, which is what task_for_pid returns without the debugger entitlement and is a real error this must never swallow.

JeanExtreme002 · 2026-08-28T14:06:25Z

Why is this PR necessary, what does it do?

A scan of a live process on macOS aborts part-way through with

MachReadError: mach_vm_read_overwrite failed: (os/kern) memory error (kr=10)

throwing away the rest of the address space. The addresses found before the bad
page survive in the results table, so the app ends up in a confusing half-state:
a populated result list and an error dialog.

kr=10 is KERN_MEMORY_ERROR, and mach/kern_return.h documents it as:

During a page fault, the memory object indicated that the data could not be
returned. This failure may be temporary; future attempts to access this
same data may succeed, as defined by the memory object.

— in deliberate contrast with KERN_MEMORY_FAILURE (9) immediately above it in
that header, whose comment ends "This failure is permanent."

So by the kernel's own definition it belongs in _PAGE_GONE_KRS alongside the
three codes already there. It was simply missed — it wasn't even defined in
macos/types.py.

Nothing else needed changing. The tolerance machinery already exists and is
already wired into all three entry points (search_addresses_by_value,
search_addresses_by_pattern, search_values_by_addresses all pass
transient_error_check=_is_transient). The code was just on the wrong side of
the line _is_transient draws, so iter_search_results and
iter_pattern_results took their raise branch and killed the scan.

Why it shows up on pattern scans first

KERN_MEMORY_ERROR comes from a pager declining to produce a page, so it
turns up on file-backed read-only mappings — code segments, dylibs, the dyld
shared cache. A pattern scan deliberately ignores writeable_only (an AOB
signature normally lives in code), so it walks those; a value scan with the
app's default "writable regions only" never goes near them. Measured on a
trivial Python process:

regions total : 148
pattern scan (regex / AOB) : 135 <- ignores writeable_only
value scan (writable only) : 58 <- the app's default
read-only regions a default value scan never walks: 77

Turning "writable regions only" off reproduces it with any value type, which is
how this was confirmed rather than assumed.

Checklist (complete all items):

Added tests as necessary.
There is no breaking change for existing features.

References:

No references to be shared.

Notes:

The new test pins both sides of the classification: the four codes a scan may
walk past, and the ones that must still reach the caller (a protection failure
or the permanent KERN_MEMORY_FAILURE) so this doesn't drift into swallowing
real permission problems.

On the machine this was found on, the entire tests/memory and tests/scan
suite failed this way — 15 tests, all with kr=10. They pass now. Worth noting
that they pass legitimately: those tests plant a value or a byte marker and
assert it is found (assert address in hits), so the scans are completing and
matching, not quietly finding nothing.

Linux is unaffected — it has its own _is_transient over a separate errno set.

A scan of a live process aborted with MachReadError: mach_vm_read_overwrite failed: (os/kern) memory error (kr=10) part-way through, discarding the rest of the address space. kr=10 is KERN_MEMORY_ERROR, and mach/kern_return.h documents it as "During a page fault, the memory object indicated that the data could not be returned. This failure may be temporary; future attempts to access this same data may succeed" — in deliberate contrast with KERN_MEMORY_FAILURE (9) directly above it, whose comment ends "This failure is permanent." So by the kernel's own definition it belongs in _PAGE_GONE_KRS beside the three codes already there; it was simply missed, and wasn't even defined in types.py. The tolerance machinery was already in place and already wired into all three entry points — the code was just on the wrong side of the line _is_transient draws, so iter_search_results and iter_pattern_results re-raised it and killed the scan. It surfaces on file-backed read-only mappings — code segments, dylibs, the dyld shared cache — which is why a pattern scan hit it first: it deliberately ignores writeable_only (an AOB signature is normally in code), so it walks 2.3x the regions a default value scan does on a trivial process. Turning "writable regions only" off reproduces it with any value type. On this machine the whole memory/scan suite failed this way; it now passes, and those tests plant a value and assert they find it, so the scans are completing rather than quietly matching nothing.

…ther Self-review follow-ups, no behaviour change. The comment justifying the fix leaned on KERN_MEMORY_FAILURE (9) as the contrast case, but that constant wasn't in types.py — leaving a gap in the sequence (2, 4, 5, 8, 10) and a comment pointing at something the file didn't contain. The module's existing convention is to define the codes it talks about even when only prose refers to them (KERN_FAILURE is already there on those terms), so the two neighbours are now defined together with the header text that separates them. The test was declaring its own copy of 9, which is the kind of local constant that drifts from the library it describes. The "must still propagate" case tested KERN_SUCCESS, a state no MachReadError can carry — MachPartialReadError is raised on success but passes KERN_INVALID_ADDRESS. Swapped for KERN_FAILURE, which is what task_for_pid returns without the debugger entitlement and is a real error this must never swallow.

github-actionsBot added macOS macOS backend changes (PyMemoryEditor/macos/) lib Library changes (PyMemoryEditor/) tests Test changes (tests/) labels Aug 28, 2026

JeanExtreme002 mentioned this pull request Aug 28, 2026
fix(app): infer the byte-array scan width from the value entered #87
Merged
2 tasks

JeanExtreme002 merged commit fd5e4a2 into mainAug 28, 2026
13 checks passed

github-actionsBot deleted the fix/macos-kern-memory-error branch August 28, 2026 16:00

JeanExtreme002 mentioned this pull request Aug 28, 2026
chore: bump version to 2.2.0 #89
Merged
2 tasks