This is my current hunch:
Both bob74_ipl and CayoImprovements are scripts that greedily request each IPL (REQUEST_IPL) on initiation. They never remove (REMOVE_IPL) them or request them only when required.
When a recording is initiated (or during additional CPacketIPL creations) all #map’s are copied to a temporary (CReplayInterfaceObject) buffer. In 2372.0 this corresponds to:
uint32_t size; // 0x141F93930 (+0x18) or (+0x41C)
uint32_t hashes[256]; // 0x141F93930 (+0x1C) or (+0x420)
// sub_1404C41B0 is the routine
On 2372, with this repro, the number of loaded #map’s will be much higher than 256 (>280). The 1604 equivalent address would be 0x141C267F0 with the number of loaded #map’s not exceeding 170.
The ERR_MEM_MULTIALLOC_FREE, and other residual issues, I presume come from the fact that there is no bounds-checking when memcpy’ing to that buffer. Hence it clobbering subsequent addresses: some of which go through the rage allocator and it thinking the memory has already been de-allocated.
While I do consider this to be a scripting issue, I suppose I could figure out how to add some user feedback/warnings into this.
(Apologies for edits, I’ve been over debugging this issue for an hour now.)