no memory for ticks generating
MetaTester build 4518, a beta released sometime after September 2, now allocates a whopping 2.3–4.4 GB of virtual memory per agent at startup. This means that a PC with 24 cores (e.g. with an Intel i9-13900 or 14900 CPU) could see a massive 106 GB of virtual memory wasted to do nothing at all. This means much less memory is available for actual work. For comparison, the previous version only consumed 0.14 GB of virtual memory per agent at startup. This is approximately a 16-31x increase in virtual memory usage! Most likely, this is the cause of the issue you are facing. As a provider of MQL5 Cloud Network agents, it caused me problems immediately on several systems after the update. It's not even allocating most of this in RAM—it's a load on virtual memory rather than physical memory, so installing more RAM won't help. And then Windows does a lousy job of automatically allocating more virtual memory as it gets used up—giving up long before actual resources are exhausted, resulting in display driver failure (hence the black screen, usually also accompanied by the system hard freezing, so no automatic restart like with a BSoD either).
@MetaQuotes @MetaQuotes Support Any idea why this change was made and what the upside was supposed to be?
Use the last released version to start with : build 4410. And not a beta (yeah I know it's sometimes hard to avoid beta pushed by MQ or a broker, but it is how it is).
If the problem persists then post more details about the backtest/optimization your are doing (dates used, modelling type, single or multiple symbols... and your computer configuration from Journal log).
If the problem persists then post more details about the backtest/optimization your are doing (dates used, modelling type, single or multiple symbols... and your computer configuration from Journal log).
I'm not sure that the actual test being done matters that much. The new massive increase in virtual memory usage shows up immediately on the start of the agents, before they're even initialized, and is dependent on the number of CPU cores. It's not that there's a new memory leak, or that certain tasks cause it to hog memory; it's wasting virtual memory up front, leaving little free for actual work later. Normal work then pushes the system over the edge into a black screen and system freeze due to running out of virtual memory and crashing the graphics driver (nothing to do with graphics; it's just what happens when you completely run the system out of virtual memory, bad things happen when system drivers and the Windows kernel fail malloc calls). The fact that this can even happen is a testament to terrible coding practices in MetaTester (indeed, judging by the tester log files, when malloc fails it appears they put it into a loop—which should never be done; they should be looking at calling TerminateProcess upon failure of malloc rather than ever daring to call malloc again—unless the intention is to crash the system on purpose).
It looks like they just released MetaTester 4523. I don't see any change in this behavior from 4522. For those curious to see what's happening, the new virtual memory wasting does show up in Task Manager if you know where to look (not at RAM usage, which is not the issue here!). You can see this bug's collective effect on the system under Performace -> Memory -> Committed. The two numbers should never equal each other (and are supposed more than 8 GB apart at all times) or the system is liable to become unstable. Windows waits until the last minute to increase the total amount available to the system, and then arbitrarily stops far before running out of actual space to do so. You can see each agent's contribution to this virtual memory burden under the Details tab after adding the Commit size column (right-click the column header -> Select columns -> tick Commit size -> click OK). Drag the new Commit column over next to the Memory column so they're side by side for comparison. Normally, these two numbers are very similar, with Commit being slightly higher than Memory, but never more than twice as much unless the system is out of RAM and the process in question has been paged to the disk. You can scroll through all the other various processes running on your system to verify this rule of thumb. But with MetaTester 4518 or newer, you'll see this is not the case; each agent starts out with a massive commit size (virtual memory usage) while continuing to use just a couple hundred megabytes of RAM as before. Upon getting work, RAM usage increases as usual, but the commit size balloons gigabytes larger. These numbers used to follow each other like they're supposed to. Now they don't. This will always cause problems and can only be fixed by the developers of MetaTester. Meanwhile, those of us who know how to work around these issues must implement workarounds for MetaTester's bad programming to avoid system crashes. Also worth noting, MetaTester 4518 (which introduced this bug) also ballooned its EXE size from 31 MB to 56 MB. Something big was changed under the hood!
I'm not sure that the actual test being done matters that much. The new massive increase in virtual memory usage shows up immediately on the start of the agents, before they're even initialized, and is dependent on the number of CPU cores. It's not that there's a new memory leak, or that certain tasks cause it to hog memory; it's wasting virtual memory up front, leaving little free for actual work later. Normal work then pushes the system over the edge into a black screen and system freeze due to running out of virtual memory and crashing the graphics driver (nothing to do with graphics; it's just what happens when you completely run the system out of virtual memory, bad things happen when system drivers and the Windows kernel fail malloc calls). The fact that this can even happen is a testament to terrible coding practices in MetaTester (indeed, judging by the tester log files, when malloc fails it appears they put it into a loop—which should never be done; they should be looking at calling TerminateProcess upon failure of malloc rather than ever daring to call malloc again—unless the intention is to crash the system on purpose).
It looks like they just released MetaTester 4523. I don't see any change in this behavior from 4522. For those curious to see what's happening, the new virtual memory wasting does show up in Task Manager if you know where to look (not at RAM usage, which is not the issue here!). You can see this bug's collective effect on the system under Performace -> Memory -> Committed. The two numbers should never equal each other (and are supposed more than 8 GB apart at all times) or the system is liable to become unstable. Windows waits until the last minute to increase the total amount available to the system, and then arbitrarily stops far before running out of actual space to do so. You can see each agent's contribution to this virtual memory burden under the Details tab after adding the Commit size column (right-click the column header -> Select columns -> tick Commit size -> click OK). Drag the new Commit column over next to the Memory column so they're side by side for comparison. Normally, these two numbers are very similar, with Commit being slightly higher than Memory, but never more than twice as much unless the system is out of RAM and the process in question has been paged to the disk. You can scroll through all the other various processes running on your system to verify this rule of thumb. But with MetaTester 4518 or newer, you'll see this is not the case; each agent starts out with a massive commit size (virtual memory usage) while continuing to use just a couple hundred megabytes of RAM as before. Upon getting work, RAM usage increases as usual, but the commit size balloons gigabytes larger. These numbers used to follow each other like they're supposed to. Now they don't. This will always cause problems and can only be fixed by the developers of MetaTester. Meanwhile, those of us who know how to work around these issues must implement workarounds for MetaTester's bad programming to avoid system crashes. Also worth noting, MetaTester 4518 (which introduced this bug) also ballooned its EXE size from 31 MB to 56 MB. Something big was changed under the hood!
I will not even read your long answer sorry.
I said you what to do, up to you to follow it if you need help, I am not interested by complaints and rants. MetaQuotes neither, believe me.
The virtual memory hogging bug introduced in beta build 4518 has been resolved in beta build 4531 released today. @mohaddeseh rohani @Au Phuong Tan @DanielDK5328 if y'all update to build 4531, the problem mentioned at the opening of this thread should no longer occur. Interestingly, the MetaTester64.exe file size (which ballooned from 31.4 MB to 56.1 MB at the introduction of this bug) has increased slightly more to 57.2 MB. But memory usage appears to be back to normal, which is what matters.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
i think after the new metatrader 5 update ,a new problem emerged for me :
2024.09.04 22:56:20.729 Core 04 pass 8 tested with error "no memory for ticks generating" in 0:00:00.036-after this if I don't close the mt5 I will encounter black screen.
and changing data ,broker , timeframe , and robot doesn't solve the problem ,I changed the ea to ma_cross example which is by default in meta_trader to be sure the bug isn't from my own code .
I have a backup version on my external hard drive and each time I replace all the folders it works fine until i close the application and after that the bug will emerge again.
does anyone has the same experience?
and also I should mention that I have 3 separate pc and all of them one by one started to show the same issue.
any advice is appreciated. Thanks