Freeing custom id of an element right after it's destroyed is causing crash
Describe the bug
After an element with custom id is destroyed, calling engineFreeModel within the same frame of destroy is causing a crash
If custom id don't have custom dff or txd, game isn't crashing
Steps to reproduce
Either:
-
Use
engineFreeModelright after an element with custom id destroyed usingonClientElementDestroy -
or use test resource
- there are few crash and nocrash commands prefixed with
efm:seecrash_producers.luafor all
- there are few crash and nocrash commands prefixed with
- start test resource
- execute
efm:createvehiclecommand - execute
efm:replacemodelcommand (no crash happens if this step is skipped) - execute
efm:crashto crash it (no crash happens iftestvehis streamed out)
Version
Client: v1.6-release-22388 (Windows 10, x64) Server: localhost, same
Additional context
- If model doesn't have custom dff or txd, game doesn't crash
- If the destroyed element is streamed out, game doesn't crash
- If
engineFreeModelis called before the element is destroyed, game doesn't crash There are more findings incrash_producers.lua, you can take a look at it. Not sure if this is all
If you are a scripter reading this and having crashes related to your custom models (or if you thinking so), to prevent the bug, put a 50ms delay to your engineFreeModel call. Can't promise it will fix :^)
Relevant log output
No response
Security Policy
- [X] I have read and understood the Security Policy and this issue is not security related.
This is because MTA does not actually destroy objects/vehicles/peds when we call destroyElement. destroyElement marks an element with the "being deleted" flag, puts it on the "delete on next tick" list, and removes it from the element list. engineFreeModel scans the element list and changes the affected model ID to a safe parent ID.