Faelucc

If you think BI "publicly acknowledged" this bug only the 2017-02-06 (when they oppened the "3FPS Issue" - Call for Help topic), you probably missed this bug report: Playing for period of time leads to low framerate (3 FPS) and never recovers, created the 2016-07-04 (and razazel is on it since the 2016-07-12). Some others bug reports may exist. Some people don't have the 3 FPS bug, so they care about the future :)

@skream That's how software development works: there is bug, and they will fix it, "free of charge" (they never said they won't). Did you ask Microsoft the same thing about their OS? If you know better than anyone what's is that bug and how to fix it, why don't you share that with us? :)

I already did a lot of tests on the 32 bits version, using several tools I know to debug a software (and investigate on memory usage)... I found a lot of things, and each time I had to check if it was related to this bug or not (and navigating through the code can be complicated without the sources...). As you can see, while I dont have a real proof, I'm not convinced. And while I'm not convinced about what I find, I don't come here to say I found something :p I wrote down the results of my tests, but they're still not precise enough. Doing tests by following stricts procedures takes a lot of time, so I'm currently waiting to be on vacation to do more tests on the 64 bits version... If the bug is fixed, fine! If it's not, but most people don't play too long and with too high graphic settings to see the symptoms, It's propably ok for them. But for the guys who can play with the settings maxed out, it may still be an issue (that's why I prefer to be sure : I don't want to hope too much and be disappointed at the end :p)

I haven't tested the 64 bits version yet, so I think it's too soon to say it fixes the 3 fps bug... Remember (and I think I'm repeating myself here :( ) : the fact the game goes to 3 FPS and/or crashes is only the "symptom", not the bug itself. The 64 bits version obviously remove (or delay) this symptom, but the only way to prove the bug itself has been fixed is to limit the memory usage with "maxmem" and check if the game memory consumption stabilise near the limit or not. If the bug is still there, the 64 bits version will allow us to play longer... but we won't be able to prevent a big "system wide" freeze...

There are 2 memory limits: * The virtual memory that can be allocated to one process: 4GB for a 32 bits process (a lot more for a 64 bits process). If a process reaches this limit, it crashes. * The physical memory, shared by all processes: Windows uses the pagefile (on your HDD/SSD) when you use more than 80% of your installed RAM (and will display a warning if the pagefile is full). Reaching 100% of used memory is not a good idea (really). If you see this warning, you should: * End some memory consuming process or * Install more RAM or * Limit the memory used by a process <== That's the point of the "maxmem" parameter in Arma 3 (it limits the "bigger" section), but the memory manager is not completely doing its job today :( So, as this Windows warning could be seen even if there were no bug in the game, we can't rely on it to do tests.

It isn't so obvious. Memory doesn't only increase because of the leak, it also increase because of the cached data (and this is normal). That's why, in all tests I do, I start by filling the memory until reaching the limit I set with "maxmem" (cached data shouldn't use more). It could be interresting to do some tests server side (setting "maxmem" low enough, and monitoring the private data section).

It was only a guarantee for the game to reach the 4 GB limit... With the 64 bits version, this limit is now your RAM (unless you have more than 17,179,869,184 GiB of RAM installed, or 16 exbibytes... no you don't). (Again...) not having the 3 fps bug doesn't mean you dont have the issue. With 64 bits, if the issue still exists, you will have the 3 fps bug as soon as your system starts to use the pagefile (and actually, all your system could become really slow). Can you prove the game will never use more memory than it should, even if you play one week in fights, with ultra settings and 10 km terrain and objects view distance? You want to know if the issue still exists in the 64 bits version? Limit the memory used in the private data section with the "maxmem" parameter, and check if, after exceeding this limit, the game still regularly allocate more memory in this section. The issue will be solved when the memory used in this section will stabilize near the limit you chose. If it doesn't, your system will use the pagefile sooner or later (and your system will be really slow... keep playing at 3 fps until the pagefile is full, and your system will crash).

If people with the "best" hardware have the issue more frequently, it may be: * because the issue is hardware related * simply because these guys tend to play with better graphic settings, and so use more memory (and reach the 4 GB limit faster) That's why I'm not playing with the 10 km object view distance anymore... can't enter into a small fight without crashing. So I think the only reason is the second one.

Really? That's a good news! Just to be sure: what did you do during these 3 days? (The leak doesn't seems to occurs if you just fly around the map with nothing else happening :p) If, at some moments during your 3 days session, you were in the fight, this is a real improvement :) Of course. Playing in ultra with a 10 km view distance is mainly a good way to fill your memory in order to do some tests (but if you want to play today, that's not the best idea ><)

I'll explain (again) about the "maxmem" parameter: When you play with the "-maxMem=2047" parameter, you limit the quantity of memory the game should use in the "Private Data" section. When you don't use this parameter, the game set the parameter itself (in most cases, with a higher value). BUT, the actual bug is: when this Private Data section is full, sometimes the game still allocate memory in it without freeing some blocks. So it use more and more memory in this section, until reaching a critical value. Ok, now what happening: * Without manually set the maxmem parameter: Your game will quickly fill almost all the memory in that section with cached data. This is normal. Then, you will only have a little more memory to allow he leak to "expand". So, you game will quickly crash. * When manually setting this parameter to 2047: Your game will quickly use 2 GB of memory in that section for cached data... The memory leak is still here, but it has more free memory to expand, that's why it takes more time to reach a total of 4 GB of memory used by the process (and crash). So with this parmeter, depending on your settings, what happen and how many time you play, you may not crash. But you still have the leak.

I did quote the wrong person, wanted to quote yesyesjo... I hope so (and it will be easy to check).

I wonder when people will understand... Not having the 3 fps bug doesn't mean you don't have the issue. Why didn't you crash in 64 bits? Because there where no memory leak? Or simply because you can now use so much RAM that you simply didn't play long enough to crash? You should check that... About this bug, this will be the difference between 32 and 64 bits: * 32 bits: your game will crash as soon as the total memory used reach 4 GB * 64 bits: your game will use as much as memory it can. When your physical memory will reach a threshold, your FPS will drop to 3... and actually all your computer will start to be really slow! If your paging file is too small, your system could crash.... Play with a view distance of 10 km in ultra settings for some time, just to try :)

This is only possible if you know where is the issue. And, if the devs knew that, the bug would have been fixed. Do you only know when the bug was introduced? There has been a lot of reports about it recently, but that doesn't means the bug is recent. It may have been unnoticed for a long time because the game (and the assets used) didn't use enough memory to reach the so known 4 GB limit (and crash). But with all the updates, some players started to use a lot more memory, and that's why we started to see reports. I'm not saying that it's the case, but it's a possibility. The only thing I know today: The game fails to limit it's "Private Data" memory section (memory allocated with the VirtualAlloc functions) to the value maxmem (manually or automatically set) under some circumstances (for example, when you die or respawn). We know when it started to be an issue, we don't know when it started to be (at all)...

Some functionnalities have been added. As spmeone said on this forum, this bug exists at least since the release of APEX. Should we remove Tanoa? :p

Hi, I don't think that "revert" to a previous release is a good solution for that kind of issue. I'm not telling that we shouldn't talk about that, but we must understand what it really means : 1. Would you agree if BI just "give up" when they face such difficulties? And how long would we wait, without any new things and improvements, if they don't update the game until that specific bug is fixed? 2. Reverting to a previous state also means less reports and less people to test things and help, and maybe more time for a fix to be found. Also, we need to remember that some players are not experiencing this issue... I'm jealous, but "forcing" them to play in a previous version for no reason (from their point of view) may not be fair too.