Repository navigation
[Bug] Decorator pool crashes after Enhanced b153 update (Pool Full, Size == 1500) #535
Closed
deenz-dev
started this conversation in
[BUG] FiveM for GTAV Enhanced
Replies: 2 comments 1 reply
|
having same issue |
0 replies
|
Hello, |
1 reply
|
So far, it hasn’t happened again to any users on the server. That said, it was something that occurred intermittently, so it’s difficult to be 100% certain. I’d say I’m 99% confident that it’s been fixed, especially since the issues that scripts were having with Decorators have also been resolved. Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Summary
After updating our FiveM for GTAV Enhanced server from FXServer early-access b139 to b153, clients started crashing due to the Decorator pool reaching its limit.
Crash message:
[ASSERT]: 0xE54EA79D Pool Full, Size == 1500
Report Code:
4b603df6-f881-4414-ac5e-cb046581dea9
This did not happen on b139 with the same server/resources.
We are also experiencing issues with scripts that use GTA/FiveM decorators after the b153 update, so this may be related to a regression in Decorator/DECOR_* handling introduced between b139 and b153.
Issue type
Client
Repro rate
Often
Server build version
b153
OS
No response
CPU
No response
GPU
No response
RAM
No response
Storage type
None
Connection type
None
ISP and bandwidth
No response
DxDiag
No response
Network graph
No response
Platform
None
OS version / distribution
No response
CPU
No response
RAM
No response
Using txAdmin?
None
Hosting provider
None
Machine type
None
/perf endpoint output
No response
DDoS protection
No response
ulimit -n value (Linux only)
No response
Docker Compose file (Docker only)
No response
Steps to Reproduce
[ASSERT]: 0xE54EA79D Pool Full, Size == 1500
The same server and resources did not produce this crash while running on Enhanced b139.
Expected Behavior
Decorator handling should behave as it did on b139.
Resources using DECOR_* natives should not cause the Decorator pool to unexpectedly reach its 1500-entry limit during normal gameplay, and clients should not crash.
Actual Behavior
On b153, clients can eventually crash because the Decorator pool reaches its limit:
[ASSERT]: 0xE54EA79D Pool Full, Size == 1500
This behavior started after updating from b139 to b153.
We are also seeing abnormal behavior in scripts that rely on decorators, which makes us suspect there may have been a regression in Decorator allocation/cleanup or DECOR_* native handling.
We have not confirmed whether entries are leaking/not being released or whether b153 changed the way decorators are allocated, but the issue was not present on b139 with the same server setup.
Evidence
Crash message:
The game has crashed:
[ASSERT]: 0xE54EA79D Pool Full, Size == 1500
Report Code:
4b603df6-f881-4414-ac5e-cb046581dea9
Working server build:
FiveM for GTAV Enhanced - early-access b139
Affected server build:
FiveM for GTAV Enhanced - early-access b153
Additional Context
The important part of this report is not simply that the pool can become full.
The same server configuration and resources were running on Enhanced b139 without reaching this condition. The issue appeared after updating to b153.
There is also precedent for regressions involving decorator natives on FiveM Enhanced. For example, an earlier Enhanced hotfix fixed DecorSetInt and other decorator natives not applying correctly.
Because of this, we suspect the pool exhaustion may be a symptom of a regression in decorator allocation, cleanup, or DECOR_* native behavior rather than simply insufficient pool capacity.
Increasing the Decorator pool size may delay the crash, but if entries are leaking or no longer being released correctly, increasing the limit would only mask the underlying issue.
We can provide additional client logs, crash report codes, or test specific DECOR_* natives if needed.
All reactions