As far as I could figure out it’s a problem with accessing the memory.
Can anybody read more out of this dmp file and help me figuring out what causes the problem? 2b6a833f-1cf1-4856-a794-74d528e093f2.dmp (6.3 MB)
We had 2 crashes today. The strange thing is, that the first crash was at 5:32 PM and the one yesterday was on 5:31 PM. Here are 2 the full Dumps of the crashes today. I’m still trying to get valid informations out of them.
my community was dying from this problem untill arifact 6318 (FiveM) was released and the problem was solved, but i can confirm we started experiencing this aswell yesterday when we had 200+ players on the server contsant crashes at least every 30 ~ 50 mins clean resource monitor no memory leaks
Instead of ‘confirming’ or assuming it’s the same issue as a prior occurrence of it, please also post crash dumps yourself, or try to deduce exactly in which build range it started to break for you again.
don’t really have any dumps from yesterday since i wasn’t expecting it to happen again so the dump thingy wasn’t activated if it helps i can get you a dump file in a week or so ( from what i remember the last dump i provided 2 months ago didn’t really help tho ;d )
Would it be possible to test the latest server artifacts (>= 6446)? These dumps make reference to NetObjEntityType::Train and the migration logic for trains has been recently updated (hopefully fixed).
These dumps were incredibly useful in debugging the issue and never trust anybody who thinks alloca is bad practice.
we downgraded to [ cmd] “version” is “FXServer-master SERVER v1.0.0.6318 win32”
[ cmd] default: “FXServer-master SERVER v1.0.0.6318 win32” - flags( )
[ cmd] type: string
and the crashes have stopped
the server was up for about 3 hours with 150+ players
something that wouldn’t last for more than 30 mins with the problem described here
no, it doesn’t ‘help’ if you’re just specifying a random build, ignoring @gottfriedleibniz’s message above, and not saying what build started breaking for you, nor did you start your own topic instead of hijacking someone else’s without adding any crash dumps or anything
its not a random build, its the exact same build that fixed that problem a month ago…
plus hijacking is not the word i would use since he could use this information himself to just downgrade and fix the problem ( which is exactly why he made this post ) and you can use it to figure out what the problem is
We tooked out our train script after your message and had no crashes since then. Thank you very very very much for the help! But to be honest we don’t like our trains that much that we would risk an other crash. But I can provide you the train script if it helps.
By the way I’m really impressed about how you can get informations out of these dump files, I just wasn’t smart enough to figure out how to really read these things
If you do find the time, or have an opportunity to, it would be greatly appreciated if you (or anybody) could test the latest artifacts (from 6446 onwards) to see if the most recent train migration fixes have stopped causing crashes.