Okay so I joined the server with my client running canary and I got this crash message. It is different than before. Imgur: The magic of the Internet
Would the server need to be updated too before it would work?
1 Like
@DamonOnYT and I face this odd bug too. I’ve just updated artifacts, not sure if that matters? will try canary now then update this comment.
No luck
1 Like
Seems an update was just pushed. somewhat fixes it
still crashing with latest artifacts 
Unless somebody else has insights, then a repro (a minified set of steps/resources/assets that guarantees issues at least some of the time) will be required. All your screenshot tells me is that a rage::fwArchetype is expected and instead nothing can be found: leading to a nullptr being accessed & deferenced.
I presume it is related to some server resource incorrectly unloading. Also, the Discord is loaded with 2189 editor-based crash messages, so I suppose if you have any repro’s for that build, this thread would be a good destination.
In my local tests, including streaming some of the more popular assets, I could use the replay editor and view clips fine (besides the oddities you would expect, e.g., non-cached assets that can no longer be downloaded in a HS_IDLE state and another unrelated something I’ll look into later).
1 Like
This logic is bollocks anyway, should just get rid of networkTimedOut and stuff related to it entirely.
And another issue is that after disconnecting from a server (ordinary disconnect, not bailout). Unless you queue to ReloadGame prior to ShutdownSessionWrap ending, the client will be in a permanent "m_gameLoaded is true when it should be false" state.
Here’s a video of whats happening?
I’m running [Releases] [Free] Cayo Perico Improvements Freeroam 4.1.4 FXServer 4471 on Linux & Game build 2372. FiveM Canary Build aswell. I had no issues before the move to the newer game build and adding in the improvements for Cayo Perico. I’ve also tested on the latest recommended FXServer build and the same issues
Canary
CfxCrashDump_2021_09_06_03_54_32.zip (1.8 MB)
Stable (Release)
CfxCrashDump_2021_09_06_04_01_33.zip (1.7 MB)
Is that the only asset you are running on a vanilla server?
At one point I was capable of hitting this ERR_MEM_MULTIALLOC_FREE 0x141602830 (2372; x-reffed to 0x1415977DC on 1604). However, that was on a server dump with many custom, and likely broken, assets.
However, on a vanilla server with only CayoImprovements I can not. Maybe somebody else has insights into this one.
I did a bit more of a search and slowly added back all my resources in my Development server. I’ve found that after I add in [RELEASE] v2: Fix holes and customize the map (bob74_ipl) Rockstar Editor failed to load. Works fine on the normal game build everyone uses but breaks on the Tuner DLC build
1 Like
Just one quick follow up: do you have custom assets loaded on this server before/after you enable bob74_ipl?
I think I have one of these issues isolated. However, it is on a server with more modified assets than what has changed for the next iteration of GTA V. I do not want to spend too much time trying to minify this if it’s something unrelated.
I stopped every map resource and started it after the Cayo improvements was started. Had no other map resources on and it had the crashing problems with rockstar editor.
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.)
1 Like
Given this is something that changes per release, would it rather make sense to somehow relocate or otherwise resize this fixed-size array, assuming it’s not used in too many weird places?
From an initial inspection, this would require a non-trivial amount of work as increasing those “buffer” sizes would have to be mirrored when processing those replay packets (e.g., 0x140137A44 and 0x1400A1419 in 1604 retail).
Given this is a patch specifically to battle against peoples misuse of loading IPLs when generating replays. Anything more than a message that tells users (more eloquently) to fix their shit just seems like a misuse of time.
1 Like
Nearly every server does this. It’s impossible to get the entire ecosystem to move on this.
1 Like
Interesting 
I’ve taken this into consideration and updated CayoImprovements.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.