Skip to content

lint: addr_class_inventory fails on main — 2 real ratchet regressions plus a stale allowlist substring #7259

Description

@proggeramlug

Step 7 of the lint job, scripts/addr_class_inventory.py, exits 1 on main (cdb3934). It is currently masked: the job stops at step 3 (#7257), so this has not been visible in CI.

Confirmed unrelated to #7256 (the file-size split) — that PR's finding set is byte-identical to main's.

There are two independent problems.

1. Two genuine ratchet regressions

  [handle-floor] crates/perry-runtime/src/child_process/value_util.rs: 3 site(s), baseline allows 1
      line 103: if ptr.is_null() || (ptr as usize) < 0x1000 {
      line 222: if opts_ptr > 0x10000 {
      line 225: if args_ptr <= 0x10000 {
  [handle-floor] crates/perry-runtime/src/fs/dirent.rs: 3 site(s), baseline allows 2
      line 132: if raw_ptr < 0x1000 {
      line 184: if raw_ptr < 0x1000 {
      line 217: if refreshed_ptr < 0x1000 {

Three new hand-rolled address floors landed without going through
crates/perry-runtime/src/value/addr_class.rs. Per the gate's own rationale these should use is_handle_band / is_above_handle_band / try_read_gc_header: a bare < 0x1000 floor does not reject the fetch/zlib/proxy handle bands, and dereferencing a handle segfaults on Linux while macOS hides it (#1843, #4004, #4665, #4800, #6271).

This is a real correctness fix, not bookkeeping — it should not be silently ratcheted up.

2. A stale allowlist entry that no longer matches its code

  crates/perry-runtime/src/object/native_module/constants.rs: [band-literal] ("O_SYMLINK", (0x200000) as f64),

scripts/addr_class_allowlist.txt has an entry keyed on both a path prefix and a line substring:

crates/perry-runtime/src/object/native_module/constants.rs | "O_SYMLINK" => Some(0x200000), | fs.constants O_SYMLINK flag value; unrelated to the handle bands (split of native_module.rs)

constants.rs contains O_SYMLINK in two syntaxes, and the entry only matches one of them:

  • "O_SYMLINK" => Some(0x200000), — matches, suppressed
  • ("O_SYMLINK", (0x200000) as f64), — does not match, so it fails the gate

Both are the POSIX O_SYMLINK fcntl flag value, unrelated to the handle bands. The fix is a second allowlist entry (or widening the substring to O_SYMLINK).

Related: pre-existing baseline staleness (warning-only)

check_ratchet also reports stale entries — counts that dropped without the baseline being lowered. These do not fail the run (they are printed after the return 1), but they are drift:

  • handle-floor | crates/perry-runtime/src/node_submodules/test.rs: baseline 2, actual 1
  • handle-floor | crates/perry-runtime/src/process/env_misc.rs: baseline 3, actual 1

Two whole-file allowlist entries also appear to suppress nothing any more and could be dropped (verified by running the inventory with and without them and diffing the output):

  • crates/perry-runtime/src/array/generic.rs | *
  • crates/perry-runtime/src/node_submodules/test.rs | *

Design note worth considering

Both the ratchet baseline and the whole-file allowlist entries are path-keyed. That makes any file split a potential gate failure even when no code changed: a ratcheted site moving to a new sibling gets baseline 0 (hard fail), and allowlisted code moving out of an allowlisted path loses its suppression. #7256 hit both and had to re-pick seams to keep specific functions in their original files. If file splits are expected to continue (#1435), it may be worth keying suppressions on something more stable than the path.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions