rage::netGameEvent pool space (pool usage vtable 0x141b1f580)

[ImBaphomettt]

What happened?

Good evening

I am reaching out with significant desperation to seek assistance.

After extensive research, I am trying to understand what might be causing this client crash. Unfortunately, I am unable to pinpoint the issue.

I appeal to any skilled and kind-hearted person for help in resolving this problem, which likely stems from my server's code.

Ran out of rage::netGameEvent pool space.

Pool usage:
unknown (vtable 0x141b1f580): 510 entries
unknown (vtable 0x141b1fef0): 1 entries

Expected result

Returned an error understandable (to me) or simply did not crash

Reproduction steps

Unfortunately, I have no idea, as I'm trying to find out the source of the problem.

Importancy

Slight inconvenience

Area(s)

FiveM, OneSync, Natives

Specific version(s)

FiveM : 2802 / FXServer-master SERVER v1.0.0.7114 win32

Additional information

I fear that my problem is not appropriate for a GitHub issue.

This issue is recurring (in my project) (759 / day for ~200 players server), and I'm starting to think that there is a problem with the code on my server.

The problem might stem from a bad practice in my code.
After more than four days of research, I still haven't found a solution. I've even reviewed the Git history of my project to reverse some changes, but the problem persists.

Thanks in advance to anyone who can help! I am available to provide any additional information if necessary.

[blattersturm]

Unrelated to the concern itself, but:

unknown (vtable 0x141b1f580): 510 entries
unknown (vtable 0x141b1fef0): 1 entries

rage::netGameEvent::GetEventName still exists, would it make sense for NetEventError to use this on b2802+ so this error would still indicate the specific event type in a more readable way? This could also help RDR2, where, even though there's no names, we're maintaining an array of names ourselves in this function.

[Disquse]

@blattersturm maybe even on all builds so it will be consistent?

[blattersturm]

@blattersturm maybe even on all builds so it will be consistent?

yeah that'd be reasonable

[Disquse]

In this specific case the problem was from calling REMOVE_ALL_PED_WEAPONS native every frame on remote peds. Depending on your use case, you should either check ped's ownership and call it each frame only on local peds or call it once in a while for remote peds.

Such crashes will be way easier to understand as of this commit:
03fdc4a