[JJDSNT]

What changed

• Check a MungWall header at the pointer supplied by the caller before applying the AllocAbs round-down fallback.
• Avoid an unaligned ULONG probe when the caller supplies an arbitrary AllocAbs address.
• Return the normalized allocation size together with the raw allocation address, so the AllocAbs displacement is included in the released range and a headerless block is genuinely freed as-is.
• Scan the live MungWall allocations when a header is missing, allowing a neighbouring broken wall to identify the allocation that overwrote it.

MungWall_Check() is an Exec-private helper; changing its size argument to an in/out pointer does not change the public Exec ABI.

Why

MungWall_Check() previously rounded every pointer down to MEMCHUNK_TOTAL before looking for the header. On m68k, AROS_WORSTALIGN is 4 while sizeof(struct MemChunk) and therefore MEMCHUNK_TOTAL are 8. A managed allocator can return a valid pointer ending in ...4; rounding it to an 8-byte boundary moves the lookup four bytes into the pre-wall.

This was reproduced on a Pi 3 MungWall boot with a 68-byte AllocVec() result: the old diagnostic reported the rounded pointer and 72 bytes, while the complete header (including MUNGWALL_HEADER_ID, the 68-byte allocation size and the correct owner) was four bytes above the address being checked. The rounded address was then handed to TLSF as though wall data were an allocator block.

The round-down is still required for AllocAbs, whose requested address may be inside the block returned by the allocator. It is now used only when the exact lookup does not find a header.

The old headerless path also returned the original address but its callers unconditionally added MUNGWALL_TOTAL_SIZE. Moving size normalization into MungWall_Check() keeps the address and size decisions paired.

Validation

• git diff --check
• mungwall.c, freemem.c and memory.c compile with -Werror using the generated AROS flags and toolchains for:
  • hosted linux-x86_64 (64-bit little-endian)
  • amiga-m68k/68000 (32-bit big-endian)
• The generated Exec target processed the modified sources' dependencies; a complete clean target was not claimed because the intentionally sparse validation tree lacks unrelated global build prerequisites.

Runtime validation of this revision on m68k hardware, 32-bit little-endian targets and 64-bit big-endian targets has not been performed.