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.

@Danny84 Your feedback seems interesting... Can I ask you to do something please ? The problem is : the REAL issue isn't the "3 fps bug", but the leak that causes it. If you don't have the 3 fps bug when playing Wasteland, it could means 3 things: 1/ You don't have the leak. 2/ You still have the leak, but it is less "intense" that when you play KotH (so you can play longer). 3/ You still have the leak, with the same "intensity", but when playing Wasterland your game use less memory, leaving more memory for the leak to "expend" and so more time before reaching the 3 fps bug (or simply crashing). As you experience the issue depending on the mode you play, could you monitor "arma3.exe" memory usage with perfmon when playing Wasterland please? To do it: 1. Launch Arma 3 (it needs to be in the process list during the configuration). 2. Open perfmon (available on a standard Windows installation, nothing to download/install) 3. Under "Data Collector Sets", right-click on "User Defined" > "New" > "Data Collector Set" 4. Choose a name, select "Create manually" and click on "Next" 5. Select "Performance counter" and click on "Next" 6. Choose a sample interval (I have selected "1 second" without experiencing any performances issue) 7. Click on "Add" 8. Click on "Process" 9. In the process list, select "arma3.exe" 10. Add the following counters to the list on the right (with the "Add >>" button), and click on "OK" : * Page Faults/sec * Page File Bytes * Private Bytes * Virtual Bytes * Working Set * Working Set - Private * Working Set Peak 11. (You are now back on the previous window) Click on "Next" 12. Choose the log file location (your desktop? :p) and name, and click on "Finish" 12. You can now exit Arma 3 if you want. 13. Next time you want to play Wasterland, please open perfmon, right-click on your new collector set (under "Data Collector Sets" / "User Defined") and click on "Start", then launch the game normally (you don't need to disable BattlEye) 14. Play play play... :) 15. After exiting the game (hopefully after some hours), use "Stop" to stop monitoring 16. Please send us the log file, or a screenshot of the result. It may look like this : This is a very easy way to "validate" that you really don't have the memory leak when playing Wasterland. It may not be as detailed as the logs provided by some tools like Dr. Memory or UMDH, but it doesn't require to stop BattleEye and it's good enough to tell us what we need to know (if you play for some hours). Thanks!!!

@M-Owen A ticket already exists (created by razazel) : https://feedback.bistudio.com/T123238 It's better to use only one ticket to simplify things.

@tomhighway Yes, this is BattlEye. Disable it and you should be able to use procdump.

Already tried long time ago, didn't work.

Still need to add the procdump files to BattlEye whitelist... A memory leak (if it's the cause of this bug) is really hard to fix. Can't explain with details in a short post, but for example: If your game crash with an "out of memory" error when there is an explosion, you can't say "the explosion was the issue". Anything could be the "real" issue (in another game, a memory leak was actually caused by the status bar, for example). More funny example: You have a bag that can contain 100 apples. But when you try put the 80th apple into this bag, it doesn't fit. Is the problem your 80th apple? Probably not, and you'll have to check "deeper" into the bag to understand what's happened before (and sometimes long before) this last action. Checking a complex code and memory dumps is hard, even with the right tools.

I have to admit, Chewz's post is very interesting... I have seen a lot of people proposing some methods which seems to "fix" the issue. They tried to help, but in general it didn't work for everyone :(. But here, Chewz is showing us a possible way to reproduce the issue (from a developer side, it's a lot more important). And, if BI developers don't test the game with BattleEye enabled, it would explain why "[they] are yet unable to reproduce said behaviour on [theirs] internal machines". It may be the cause of the issue, or not... In any case, this is a really good "new point to check", so thanks a lot for that feedback! At least it gives me hope again :D

You should be able to use the "procdump arma3.exe FreezeMiniMemoryDump.dmp" command (without a "-h") to do a dump when you want to. We can't create a dump when BattleEye is active. I don't know if killing/disabling BE just before to use procdump is "safe" or not.

Hi! Because it is related, and not everyone reads SITREPs, here a quote from SITREP #00186: Here the link for twitter: The need to use a dump of the process memory proves that it's more complex than an already complex memory leak :( I'll provide that when i can, and wish you good luck!

No, I'm not using any mod. Yes, cause it seems it's a memory leak. The hard part is to find what should be freed and curently isn't. That's why some people say that going to 64 bits will "solve" the issue (ability to use more memory). Actually, it will only "delay" the issue, AND you will have to limit the memory used by the game if you don't want to have 3 fps (or less) when your OS will start to use the swap (your RAM will be full at this moment)... As i don't use any mod, I'm pretty convinced the leak occurs in the base game :p

Here the result: Command line parameters: "C:\Games\Steam\steamapps\common\Arma 3\arma3.exe" -exThreads=7 -enableHT -maxmem=2047 -mod= Played for 1h45 on 2 differents PvE servers. On Altis with infantry, ground and air vehicles (as passenger), explosions, heavy fights, lots of AI, more than 50 players (everything you can expect in Arma 3...). I played for >1h longer than usual, but this is "normal" when i reduce the view distance to 1600m (which was the case here, cause i forgot to change the server specific settings...) In the rpt file, as always: "DX11 error : CreateTexture failed : E_OUTOFMEMORY" several times during the 3fps drop (with a lot of memory stats), and repeated at the end of the logs (cause of the crash). So it seems to be the same bug with and without the "-maxmem=2047" parameter :(