Mtasa-blue: MTA crashing when reconnecting

[Einheit-101]

Describe the bug
This bug happened often to me, but it seems to happen even more often now, basically almost everytime i reconnect to my server using /reconnect. I dont know why.

To Reproduce

1. Go to my server (SAAW World War II)
2. /reconnect
3. Crash to desktop

**MTA Version r14378

Additional context
Crash dumps attached

crashs.zip

Version = 1.5.6-release-14378.0.000
Time = Thu Sep 13 23:30:29 2018
Module = D:\GTA San Andreas\gta_sa.exe
Code = 0xC0000005
Offset = 0x000D41F8

EAX=3A3EABA0 EBX=00000001 ECX=FFFFFFFF EDX=FFFFFFFF ESI=47BC42C0
EDI=502A8828 EBP=47B8E9C0 ESP=0177FCF4 EIP=004D41F8 FLG=00210206
CS=0023 DS=002B SS=002B ES=002B FS=0053 GS=002B

[saml1er]

Okay, I made sure I was using the latest nightly this time r14378. I can't reproduce the crash. I joined the server, spawned, drove around in tanks and reconnected, still can't reproduce.

[Einheit-101]

It looks like it has something to do with custom animations... A crash also occurs sometimes when i restart the custom animation resource while certain custom animations are in use. However in that case i dont even get a crash dump. I restart custom animations and the game simply freezes and shuts down without a warning a few seconds later.

What does the crash dump say? This seems to be pretty random, as i can not always reproduce it by reconnecting/restarting resource while using custom animations....

[Dutchman101]

The reason saml1er was the one to respond initially, was because your crash is related to custom anims. There's just a bunch of crashes to weed out, but which do not occur in typical usage scenarios (but in those that you can argue it should still not crash). Tendency to crash is higher for example when there's high RAM usage, low system RAM or specifications, or when there are random events that are not typical (such as you mentioned, maybe restarting resources.. clients that are already predisposed may crash, often on quit or reconnect too so the harm is limited).

I am just saying, for the average user, the custom anims integration is very stable and I have personally played on IFP-enabled servers with both low and high-end systems (lengthy gaming sessions) without ever witnessing one crash. MTA has crashes in other categories and modules & SA, that upon further investigation simply turn out to be an issue we cannot help and somehow depend on the user's environment.

There's been a few recent IFP changes that tackled the root causes of various crashes, and we will still not settle with predisposition for crashing, so that's why @saml1er is still working on a list of crashes to fix. The crash on your offset is part of it.

• Please note that lots of anim-related offsets have seen various different crashes occur on them, there's even pre-IFP implementation crash offsets which had a raising crash incidence post-IFP, so it is tricky to memorize this or any anim-related offset as definately caused by custom anims.
  This also makes investigation harder (as we'll have to check extended callstacks to make sure we are looking at the crash we expected). Not to talk about the filtered results from those offsets that are infact related to IFP, but are caused by system (issues)/running out of RAM, provoked by scripts that seriously abuse performance-heavy code and predispose clients running a weaker PC to crashes, etcetera.

TL;DR - we are working on investigating and eventually fixing (or if it's not really our fault, averting) this crash, it was already on the list, so please wait.

[Einheit-101]

Dont worry, this crash is not very important because it doesnt affect gameplay, so take your time

[saml1er]

I was able to reproduce the problem while working on engineRestoreAnimation. Fixed in 80bb8988895c537d841409eceed8d5af67d6ac4c. Looks like it's unrelated to this. This one needs some investigation.

[botder]

56ead0bd4191c143d789087b454b88baf99996a9 might have fixed this. Please test.

[botder]

Can't reproduce.