SetPlayerModel Crash when you have too much .ymts assigned to a freemode ped model

FiveM Discussion Bug reports
1
  1. Client (production/canary) and FXServer version
  • Client: Both | Server: Any?
  1. What you expected to happen
  • To not crash when i use SetPlayerModel on a freemode ped model with extra 5/7/15 [B2372/B2189/B1604] ymts assigned to it.
  1. What actually happens
  • It crashes when you assign 5/7/15 [B2372/B2189/B1604] extra ymts to a freemode ped model and uses the SetPlayerModel native.
  1. Category of bug (eg. client, server, weapons, peds, native)
  • Client/Peds
  1. Reproducible steps, preferably with example script(s)
    Start the repro resource according to your game build, and use the SetPlayerModel native with any GTA:O freemode ped (mp_m_freemode_01 or mp_f_freemode_01) to see the crash ocurring.

Repro resource (B2372 only): CrashClothes2372.rar (7.8 KB)
Repro resource (B2189 only): CrashClothes.rar (12.2 KB)
Repro resource (B1604 only): CrashClothes1604.rar (22.5 KB)

Crash image on B2372:

crash b2372
crash b23721515Ă—121 106 KB

Crash image on B2189:
Addon Clothes Crash
Addon Clothes Crash1538Ă—101 107 KB

Crash image on B1604:
image
image1547Ă—62 48.8 KB

B1604: Limit of extra .ymts assigned to a freemode ped: 14 (15+ will crash)
B2189: Limit of extra .ymts assigned to a freemode ped: 6 (7+ will crash)
B2372: Limit of extra .ymts assigned to a freemode ped: 4 (5+ will crash)

Crash hashes for each game build:
B1604: oven-happy-sad || GTA5.exe!sub_1406B14FC (0xf)
B2189: earth-august-saturn || FiveM_b2189_GTAProcess.exe!sub_1406D21B0 (0xf)
B2372: yellow-stairway-december || FiveM_b2372_GTAProcess.exe!sub_14070E7A8 (0xf)

Even mp_creaturesmetadata ymts will count on this crash, thats why on B2189 the limit has decreased in 8 units, due to the addition of mpvinewood, mpheist3, mpsummer & mpheist4 (each one adding 2 ymts).
And in the B2372, the limit has decreased in 2 units (in comparison to the B2189) due to the mptuner addition.

3 Likes
2

Did you manage to solve it somehow? I also noticed that this is happening

3

B1604 has that limit too, but it’s pretty higher than B2189. Today i hit the crash with 15 addon clothes packs, while B2189 it’s occur when i hit 7 or more. So it’s not related only to B2189.

Log on B1604:

InvokeNative: execution failed: Error executing native 0x00a1cadd00108836 at address 0x1407a0b54.
SCRIPT ERROR: Execution of native 00a1cadd00108836 in script host failed: Error executing native 0x00a1cadd00108836 at address 0x1407a0b54.^7
SetPlayerModel^7 (^5SetPlayerModel.lua^7:7)

1 Like
4

The same thing is happening to me, every time I try to put on men’s addon clothes it crashes me but the women’s doesn’t

[    243609] [b2060_GTAProce]             MainThrd/ InvokeNative: execution failed: Error executing native 0x00a1cadd00108836 at address 0x1407baccc.
[    243609] [b2060_GTAProce]             MainThrd/ ^1SCRIPT ERROR: Execution of native 00a1cadd00108836 in script host failed: Error executing native 0x00a1cadd00108836 at address 0x1407baccc.^7
[    243609] [b2060_GTAProce]             MainThrd/ ^3> SetPlayerModel^7 (^5SetPlayerModel.lua^7:7)
[    243625] [b2060_GTAProce]             MainThrd/ ^3> fn^7 (^5@spawnmanager/spawnmanager.lua^7:263)
[    243625] [b2060_GTAProce]             MainThrd/ InvokeNative: execution failed: Error executing native 0xe0a7d1e497ffcd6f at address 0x14060d1e5.
[    243640] [b2060_GTAProce]             MainThrd/ ^1SCRIPT ERROR: Execution of native e0a7d1e497ffcd6f in script host failed: Error executing native 0xe0a7d1e497ffcd6f at address 0x14060d1e5.^7
[    243640] [b2060_GTAProce]                23440/ ResourceCache::AddEntry: Saved cache:v1:7296d8241e68bfa46f5c17c01e32044bbc12e264 to the index cache.
[    243640] [b2060_GTAProce]             MainThrd/ ^3> SetPlayerWantedLevelNow^7 (^5SetPlayerWantedLevelNow.lua^7:5)
[    243640] [b2060_GTAProce]             MainThrd/ ^3> fn^7 (^5@av_D-Dispatch/client.lua^7:92)
1 Like
5

New informations i got after doing some research:

  1. The crash is not related to the amount of Clothes packs loaded. It’s related to the amount of .ymts assigned to a ped model. Even mp_creaturesmetadata ymts will cause that crash.
  2. It’s not related only to B2189, it’s can happen too on B1604. The difference is: On newer builds, the amount of ymts already assigned to MP Peds are higher than in older builds. For example: Cayo Perico Build has 8 more ymts assigned to every MP Ped than B1604 (4 CPedVariationInfo & 4 CCreatureMetaData) due to the last 4 DLCs added into the game (Diamond Casino, Casino Heist, Summer & Cayo Perico). So, i added a new repro resource to B1604 too.

Hope those infos can help in order to trace that.

1 Like
6

Appears to be a case of rage::fwMetaDataStore (.#mt streaming module) not having loaded some specific requested metadata file, but the game assuming it would have.

Might just be a maximum size in some request list.

7

… oh, no, don’t say this is fwArchetypeStreamingModule::GetDependencies (overridden as CModelInfoStreamingModule) ending up with a maximum amount? This metadata store entry is also used from the resource-paged-in callback in CPedModelInfo, so that’d imply this metadata has to be loaded before the MI is loaded…

8

Correct. A CPedModelInfo gets some long list of .#mt files added as dependency before streaming in, and despite Rockstar’s best efforts to pass a limit of 80 (direct and indirect?) dependencies to this fetch in rage::strRequestMgr::RequestObject, I guess that’s… not enough.

1 Like
9

Not sure if this is trivial to fix, stack-allocated bits and I’m really not feeling like having a function with this many downstream dependencies change its stack frame size leading to exception handling getting really confused. :confused:

10

Done.

1 Like
11

Thanks. I tested it on B1604 and it’s working nicely.

One question: Is this fix supposed to be working on B2189 too? I tested both builds, and the game still crashing on B2189, but now with a different crash than the previous reported one:

image
image1653Ă—226 14.9 KB

Dump file generated: 57abf15e-67a7-41f7-8398-7e0ebc98b8e4.dmp (5.1 MB)

12

Might be hitting another limit there, maybe.

13

Yeah, really seems. I tested the previous repro resource to B2189 and it is not causing that new crash. I’m looking into it to know what is causing it to provide a new repro resource for that.

14

This repro resource to B1604 is now triggering that new crash on B2189. (Difference between those repro resources: The B1604 one has more .ymts & .metas than the B2189).

15

Right, seems there’s way more places with the 80 item limit, many of which not trivial to patch.

1 Like
16

Might’ve found another workaround here.

2 Likes
17

Both builds are working properly now. Thanks!

18

This fix and the other one have been backed out since a number of servers were having new, unreproducible crashes with remarkably high prevalence.

1 Like
19

Hi, could you make this FIX again? Since we are also having this issue, and now when we join our server, we get instant crash. I dont think this one issue could be the one that making other crash? We tested it on canary version of FiveM and did not have any issues. Thank you.

20

Oh, it’s sad but i understand. If you want to test another fix approach someday, i will be here to help testing it!

1 Like