Closed Kxnrl closed 4 years ago
I think use PushArray should be better.
I created a pull request https://github.com/shavitush/bhoptimer/pull/865
https://crash.limetech.org/sd4koxxvvvvw
crashed on release build and my custom build. more dumps failed.
Both Resize and PushArray call CellArray's GrowIfNeeded function which is the check that throws that exception. https://github.com/alliedmodders/sourcemod/blob/22eeb2f3a56849141ed068483adc1a511fa86100/core/logic/CellArray.h#L174 https://github.com/alliedmodders/sourcemod/blob/22eeb2f3a56849141ed068483adc1a511fa86100/core/logic/CellArray.h#L85 https://github.com/alliedmodders/sourcemod/blob/22eeb2f3a56849141ed068483adc1a511fa86100/core/logic/smn_adt_array.cpp#L203 https://github.com/alliedmodders/sourcemod/blob/22eeb2f3a56849141ed068483adc1a511fa86100/core/logic/smn_adt_array.cpp#L119
So #865 will most likely not solve your issue. And with that pull request all replays would be reversed since new frames would be put at the start of the arraylist and not at the end. I'm sorry I don't have an answer for your issue, it seems to be that your server is running out of memory before it even reaches the dynamic limit set. I'd recommend asking in the sourcemod discord as someone who might have experience this kind of issue might be able to help more.
I host on 9900X and 32G RAM, so I think memory is not a problem, PushArray is push_back function, not is start of array list. btw I changed that code and no crashes in 48 hours. so I don't know why.
Your server's specs are not relevant to the issue. I have a strong feeling that SourceMod refuses to allow the ArrayList to resize to more than the #pragma dynamic N
setting for whatever reason.
Pretty much SOL here. There's 3 options:
enum REPLAY_FLAGS
{
RF_ATTACK = (1 << 0),
RF_ATTACK2 = (1 << 1),
RF_USE = (1 << 2),
RF_ONGROUND = (1 << 3),
RF_PARTIALGROUND = (1 << 4),
RF_INWATER = (1 << 5),
RF_SWIM = (1 << 6),
RF_ONLADDER = (1 << 7)
};
struct replayframe_t
{
float fPos[3];
float fAngles[2];
uint8_t nFlags; // perhaps fill only the 3 first bits to support IN_ATTACK, IN_ATTACK2 and IN_USE. 4th-7th bits for entity flags and 8th bit for ladder
};
std::vector<replayframe_t> aFrames;
This way you have absolute control over it and it also optimizes the struct to use 21 bytes rather than 32 bytes per frame. It's superior by every mean - less memory overhead and almost half the size on disk. I didn't really know C++ back when I wrote the timer and nowadays I don't have the time to work on it.. if anyone feels like implementing this, feel free.
I think #pragma dynamic max value is 131072
now I am trying max record time with 1800 seconds
can confirm windows 32 bit srcds limit with 3.25GB RAM and freezing. I am checking shavit-repaly for memory leak. If i disabled that, srcds max ram usage is 1.5GB with 40 player slots.
there is no 64bit srcds
delete handle has no permission with HandleSecurity
Can you please stop making this some kind of a blog? You got a problem with the timer, we get it, but you provide no logs, nothing.
You might as well do that on discord instead.
That's not a problem with the timer itself, it's your config.
It's a memory leak bug, not for me, but linux use 64bit srcds, so not freezing with memory limit. I shared a crash id, there is no any errlogs.
There is no such thing as 64bit srcds. The application is 32bit. Eh.
If you're having a memory leak, then it's something else. The timer is just fine. You are running out of memory somehow. I don't know how and where and why.
@Kxnrl, do file srcds
on binary
also you probably want to dump and inspect handles with one of available inspectors/analyzers to see what plugins use a lot of memory
look like
not working
make server freezing...