fivem icon indicating copy to clipboard operation
fivem copied to clipboard

Crash when spawning peds on the server with createped using artifact 5790 and newer

Open gewrutv opened this issue 1 year ago • 8 comments

pedtest.zip CfxCrashDump_2022_08_10_11_50_36.zip

I have discovered an issue that exist in artifact 5790 and beyond with spawning peds on the server. It appears whenever I spawn peds on the server that will be owned by another client it will then crash the client or even potentially both clients. The above resource, pedtest, is the resource I created to reproduce this issues. I have also added links to videos showing the testing. Spawning the peds on the client has no issues at all.

pedtest - artifact 5789 - https://streamable.com/lhj3yu

pedtest - artifact 5799 - https://streamable.com/q0kl25

The attached files are the resource and the crash dump from the client.

gewrutv avatar Aug 10 '22 12:08 gewrutv

Thanks for the repro - someone had previously reported something regarding this but didn't have a repro so it wasn't really able to be looked into (don't really have much time for random wild goose chases).

This'll be looked into whenever possible.

blattersturm avatar Aug 10 '22 13:08 blattersturm

OK, this is a bit weird:

  1. You didn't specify how to use the repro (apparently have to set coords to crun SetEntityCoords(PlayerPedId(), vector3(2379.44, 5060.68, 46.44)) and then run pedtestserver somewhere).
  2. I'm probably doing something else wrong, as my game remains functioning fine when using pedtestserver on current client/server code (although using build 2699), even when flying back and forth and ownership transfer is definitely happening.

blattersturm avatar Aug 10 '22 16:08 blattersturm

OK, this is a bit weird:

  1. You didn't specify how to use the repro (apparently have to set coords to crun SetEntityCoords(PlayerPedId(), vector3(2379.44, 5060.68, 46.44)) and then run pedtestserver somewhere).
  2. I'm probably doing something else wrong, as my game remains functioning fine when using pedtestserver on current client/server code (although using build 2699), even when flying back and forth and ownership transfer is definitely happening.

Yes, sorry I should have specificed to TP to those coords. This is part of our chicken catching script so I was spawning the peds at a specific spot. It only seemed to happen when spawning the peds tried to transfer ownership directly after the peds had been spawned. CfxCrashDump_2022_08_10_18_34_20.zip

I was able to duplicate the crash on 2699 as well and have include new crash logs

If you want to save yourself some trouble you can use RegisterCommand('tptotest', function() SetEntityCoords(PlayerPedId(), chickenSpawns[1]) end)

This is on artifact 5799 with build 2699

gewrutv avatar Aug 10 '22 18:08 gewrutv

CfxCrashDump_2022_08_10_19_01_15.zip

I wanted to get someone else to help test instead of using cl-2 we are able to reproduce the results on 2699 two completely independent clients. These are his crash logs.

gewrutv avatar Aug 10 '22 19:08 gewrutv

I'm still not able to replicate this issue. I suspected this to be a retail/debug build difference, but even with retail client/server (5800, current one) I'm not able to get the game to crash at all around this area with the server-side chickens, despite ownership transfer on them definitely happening between the two local clients.

~~Is there anything else I could be missing?!~~

... ah, from your comment above:

It only seemed to happen when spawning the peds tried to transfer ownership directly after the peds had been spawned.

Running pedtestserver a few more times with players some sufficient radius apart does seem to have the expected behavior on the retail build setup at least, yes.

blattersturm avatar Aug 11 '22 12:08 blattersturm

Mildly curious, however, is that I can't reproduce this crash on my local server working tree which had some other fixes applied regarding 'first-frame updates'. It could be something regarding server-side rejection of script disowning actually breaking something without the first-frame update fix, but relying on that interpretation is a little risky.

blattersturm avatar Aug 11 '22 12:08 blattersturm

That commit seems to have fixed the issue, I'll try this out in production tomorrow and see if it has any unintended side-effects

AvarianKnight avatar Aug 11 '22 23:08 AvarianKnight

GitHub, please. The commit said 'didn't fix #1565', not 'fixes #1565'. 🤦🏻

blattersturm avatar Aug 13 '22 15:08 blattersturm

Can we get an update or an ETA of when this will be resolved?

AngelofDeathGaming avatar Oct 10 '22 15:10 AngelofDeathGaming

Can we get an update or an ETA of when this will be resolved?

This has been resolved as of build 5810 - 2 months ago! - via https://github.com/citizenfx/fivem/commit/12178006c7663edca6dfa756f799981738297dd2 (as the change causing this issue, https://github.com/citizenfx/fivem/commit/dd2e1c9235fb00b9b908929a896d769613aab94e, was reverted). This issue was only left open so that it could be tracked whenever reintroducing the latter change.

blattersturm avatar Oct 10 '22 16:10 blattersturm