Crash: `mmap` access can `SIGBUS` after backing file is truncated

Bug report

Bug description:

Summary

An mmap.mmap object can become internally inconsistent after its
backing file is truncated to zero.

After truncation:

• m.size() reports the new file size correctly
• len(m) still reports the original mapping length
• ordinary access such as m[0] can crash the process with SIGBUS

I think it's a genuine question whether the correct "fix" is a
paternalistic change in C behavior or just adding a more prominent
warning in the docs about the pattern and OS differences, but it
does seem particularly pathological in its current form.

Minimal Reproducer

import mmap
import tempfile

f = tempfile.NamedTemporaryFile()
f.write(b"\0" * 4096)
f.flush()

m = mmap.mmap(f.fileno(), 4096)
f.truncate(0)
f.flush()

print(m.size())  # 0
print(len(m))    # 4096
print(m[0])      # SIGBUS

On my system this exits with SIGBUS / exit code 135. I tested all the way
to 3.8 and got the same SIGBUS every time, so at least this isn't new.

Expected Behavior

If the mapping becomes invalid because the backing file shrank, I would
expect CPython not to keep exposing the old length and then hard-crash
on a normal operation.

Actual Behavior

The object still looks readable according to len(m), but using that
range can crash the interpreter.

Additional Affected Operations

I was able to hit the same SIGBUS with more than just m[0],
including:

• find
• rfind
• readline
• read_byte
• write_byte
• move
• memoryview(m)
• bytes(m)
• slicing
• iteration

Behavior Sketch

flowchart TD
    A["create mmap of 4096-byte file"] --> B["length is 4096"]
    B --> C["truncate backing file to zero"]
    C --> D["reported file size becomes zero"]
    D --> E["reported mapping length stays 4096"]
    E --> F["access first byte"]
    F --> G["SIGBUS"]

Related Issues

I realize there have been older mmap / SIGBUS reports around
resized underlying files, but this truncate-to-zero case still
reproduces for me on a currently supported CPython release.

• #60416
  mmap() dumps core upon resizing the underlying file
  Closest historical peer. Same broad pattern: the backing file changes
  after mapping, and later access crashes. Old migrated issue, but still
  the strongest prior-art reference I found.

• #84897
  accessing mmap of file that is overwritten causes bus error
  Related. Same end result (SIGBUS) after the underlying file
  contents/extent change, but a different trigger than truncate-to-zero.

• #119817
  SIGBUS: writing to mmaped device beyond file size
  Related, but not a duplicate. Same bug class: the Python-visible
  mapping range still looks usable, but the OS faults on real access.
  Different scenario: mapped device / write beyond real extent.

• #114390
  SharedMemory crashes on linux with SIGBUS on insufficient shm
  Related, but not a duplicate. Same OS-level failure mode: mapping
  succeeds, later access faults with SIGBUS. Different subsystem:
  multiprocessing.shared_memory.

CPython versions tested on:

3.14

Operating systems tested on:

Linux

Start with the minimal Python reproducer and compare its truncate-to-zero behavior with related issues #60416, #84897, #119817, and #114390. Determine whether the accepted resolution is a safe mmap behavior change or clearer documentation, then verify that the chosen outcome prevents or clearly addresses the reported SIGBUS scenario.