Metatrader known bugs ... - page 61

 
pro34159:
Hello,

if, when using the debugger, you cannot see the variable value in the "Watch" tab add this piece of code before start or OnTick:

class CFix { } ExtFix;

Bye

Beautiful : now we have to fix the debugger too

What should help us to find errors has errors too

 

I can share a nice dynamic bug in the 600+ terminal.

Using iBars() or ArrayCopyRates() or similar command reaching other timeframe usually initiates load of the other timeframe chart data.

But in combination with the other known bug (indicators do not unload after account/broker change) those commands do not initiate load of other timeframe data after account server change. The iBars returns 1 or zero, CopyRates keeps failing.

You can temporarily "fix" it by opening the targeted timeframe chart, BUT after this chart gets closed, the iBars returns zero again.

The workarround I am using is ChartSetSymbolPeriod(0,_Symbol,_Period)after server change has been detected.

 

The problem is that we are just finding new and new bugs. And we are not finding that the old are corrected

 
checkin:
The problem is that we are just finding new and new bugs. And we are not finding that the old are corrected

New language-new bugs. That one I can understand. What makes me cry is that they keep the old bugs.

 

They are losing what made them popular and they do not understand it yet : the broad base of coders. If they think that their "code base" can replace that they are in for a big surprise. What they have there is already half that does not work, a quarter that is a bs and the rest is buried and forgotten or coders abandoned metatrder (like qwpr that does not want to post there any more and a lot of other coders that do not want to touch anything there any more)

And with "moderators" there it is going to get just worse and worse.

 

Has anyone noticed how if you leave build 670 running for any length of time the ram and cpu usage on the computer starts to go up and even moving the cross hairs across a chart is lagging and every time you try to do anything it lags and you get delays, then if you close the MT4 and MetaEditor then reload everything returns to normal? plus the build 670 takes forever to load up when starting.

Personally I have just about had enough of the total unprofessional disregard for anyone trading with MT4 let alone programming with MT4 and am very close to just walking away from this whole mess, how is anyone supposed to work with software that is constantly changing in fundamental ways and often as not is worse after the latest update than it was previously. Sure it is free but that can only cover so many issues and this time MT4 has not only shot themselves in the foot but it was in their mouth when they did it.

 
cja:
Has anyone noticed how if you leave build 670 running for any length of time the ram and cpu usage on the computer starts to go up and even moving the cross hairs across a chart is lagging and every time you try to do anything it lags and you get delays, then if you close the MT4 and MetaEditor then reload everything returns to normal? plus the build 670 takes forever to load up when starting. Personally I have just about had enough of the total unprofessional disregard for anyone trading with MT4 let alone programming with MT4 and am very close to just walking away from this whole mess, how is anyone supposed to work with software that is constantly changing in fundamental ways and often as not is worse after the latest update than it was previously. Sure it is free but that can only cover so many issues and this time MT4 has not only shot themselves in the foot but it was in their mouth when they did it.

So far I did not notice dependency on time, but I registered some people were complaining. It seemed to be locale dependent (those people from Asia).

I noticed another memory issue: using iBars or ArrayCopyRates or similar command allocates additional memory in every script and also it depends on chart length. E.G when you have like 65k bars on every timeframe and you call iBars inside indicator or Expert for all timeframes, memory used by Metatrader steps up by 100MB. If you deploy 10 such indicators, then Metatrader consumes 1GB additional memory to count bars on timeframes in 10 indicators.

 
cja:
Has anyone noticed how if you leave build 670 running for any length of time the ram and cpu usage on the computer starts to go up and even moving the cross hairs across a chart is lagging and every time you try to do anything it lags and you get delays, then if you close the MT4 and MetaEditor then reload everything returns to normal? plus the build 670 takes forever to load up when starting. Personally I have just about had enough of the total unprofessional disregard for anyone trading with MT4 let alone programming with MT4 and am very close to just walking away from this whole mess, how is anyone supposed to work with software that is constantly changing in fundamental ways and often as not is worse after the latest update than it was previously. Sure it is free but that can only cover so many issues and this time MT4 has not only shot themselves in the foot but it was in their mouth when they did it.

That would mean that the garbage collection in new metarader is not working OK. That is their problem ever since they started with the "new" metatrader - and they are not able to solve it

 

I apologize to non-programmers, that this entry is somewhat advanced.

Actually I have been fighting this long time, and I was not able to sort it out in full.

I already wrote about a "feature" that though the MQL4 events are queued according to the documents, actually they are implemented in a different way.

My first thought was that events interrupted the thread that fired them, start a handler method and after the handler method had finished, the original thread continued.

But now I am not sure of that. It seems more likely, that the events (both timer and chart events) are proceeded concurrently in additional thread.

And it seriously interferes with the caller method causing unpredictable crashes, like in the later example.

According to my trace logs, this sometimes happen:

  1. method A starts.
  2. method A fires event
  3. event handler B starts, while A still running
  4. method A finishes
  5. event handler B crashes because the method A changed its data meanwhile

See some real example of such crash in timer handler. A runtime error has been thrown:

2014.09.28 13:09:39.264 invalid pointer access in 'MT4BaseManager.class.mqh' (177,58)

I emphasized the location of the error in the code.

MT4TimerListener* listener = iter.next();

if (isNull(listener)) {

timerListeners.remove(listener);

continue;

}

// checkEvent returns true if on schedule and triggered, false if not yet

else if(listener.checkEvent(currentTick) && !listener.isRepeating()) {

So the listener was 2 times a valid pointer, while with the third access it was already destroyed(!).

It is totally unsafe implementation of a muliti-threaded program. Moreover, the documentation lies about the implementation, and you have no idea that it is multi-threaded.

 

Ovo

Metatrader never had any idea at all about asynchronous executions : if they have tried to do anything of a sort, then there is no wonder that orders are opened on a wrong account, that event handlers are crashing terminal ... They should have studied how a PDP 11-70 was able to handle 16 parallel processes 40-45 years ago before starting to invent their own asynchronous handling. They are simply not capable of making that

Reason: