Bug mql4 build 616 - Dynamic Array of objects leaked in Expert

 

Raised on Service Desk

EDIT: Posted here for visibility.

// Dynamic Array of objects is leaked.
 
#property strict

class MyClass {
};

MyClass array[2];
MyClass single;

int OnInit()
  {
   return(INIT_SUCCEEDED);
  }

void OnDeinit(const int reason)
  {
  }

void OnTick()
  {
  }

Output:

2:15:36 Expert static2 EURUSD,M1: loaded successfully
02:15:36 TestGenerator: spread set to 20
02:15:38 static2 test started
02:15:38 2013.07.16 23:59 static2 EURUSD,M1: 2 undeleted objects left
02:15:38 2013.07.16 23:59 static2 EURUSD,M1: 2 objects of type MyClass left
02:15:38 EURUSD,M1: 397152 tick events (8181 bars, 398152 bar states) processed within 63 ms (total time 2605 ms)

 
There are tons of bugs in the new compiler. You may report them if you wish them fixed, but sharing them in the forum is redundant - no reason for discussing minor bugs, which will be probably fixed soon.
 
Ovo:
There are tons of bugs in the new compiler. You may report them if you wish them fixed, but sharing them in the forum is redundant - no reason for discussing minor bugs, which will be probably fixed soon.

I completely disagree. I dont think sharing them is redundant at all. Other developers dont have visibility of the bugs, and that was the reason for sharing. A "thank you" would've sufficed :)

1. I'd like to know what other current bugs are so I don't waste time troubleshooting them, preparing test cases, and submitting to the service desk if someone else has already.

2. Things that appear minor to you might not be to someone else

3. The new compiler is official now. If the new compiler is this buggy then developers need to know. esp if these bugs are also present in the 610 build.

In fact I'm wondering what the motivation is here, for a developer to support hiding bugs from other developers, even though it may save others time. Fully understand that behaviour from MQ themselves though.


Of course if bugs are subsequently fixed, then the thread should reflect that (that is one reason I've added the build number).

I am considering holding off development until the next compiler release, because I have to make too many code changes to work around this bug and losing confidence...

 
ydrol:

I completely disagree. I dont think sharing them is redundant at all. Other developers dont have visibility of the bugs, and that was the reason for sharing. [...]

100% agree with you. Thanks for sharing this information. (Also worth bearing in mind that many of these compiler bugs have presumably existed in MT5 for years.)
 
Well, two threads started for a glitch that has left unnoticed for four months and now it is reported and gets fixed probably in the next release. Why not.
 
Ovo:
Well, two threads started for a glitch that has left unnoticed for four months and now it is reported and gets fixed probably in the next release. Why not.
I'll tell you why not (or rather why) - though I suspect you just want to take an opposing stance regardless ....

Ovo: two threads started for a glitch

1. They are two separate issues, so ... two separate threads. Is that really a big issue for you? They could be in one thread, but I suspected having separate threads would make it easier for others to find. Personally, I'm not a fan of 'bucket' threads.

2. "glitch" Nice attempt to trivialise the issue but the original fault is far from a glitch. Just one effect of it: Presumably you know what a Singleton is and how well used it is in serious OOP design and development. Well the original 'glitch' directly affects typical implementation of a singleton on MQL4.

And even the 'minor' leakage bug reported here could still cause developers to waste time trying to find the leaked memory. Reporting it here might save someone some time, even though the leakage is relatively harmless.

Just because its not important to you doesn't mean it's not important to someone else.

Ovo: left unnoticed for four months

lets be honest, only as more developers start using MQL4 OOP features more seriously, the bugs will come to light - we both know this is the reason they have gone unnoticed for four months.

They might even have been already reported to the ServiceDesk by others, but how would I know ?

I also find it slightly concerning that I happened to stumble upon one relatively minor bug, whilst preparing a case for a more serious scoping issue (or 'glitch' as you call it).

If you don't want to see current compiler bugs reported that's fine, just ignore any threads discussing bugs and continue with whatever coding you are currently doing.

I personally want to see other peoples submitted bugs too !

Bottom line. In addition to submitting to the ServiceDesk, I will continue post any bugs I find here if I think they might save others some time troubleshooting. So you can decide what you want to do.

 
Ovo:
Well, two threads started for a glitch that has left unnoticed for four months and now it is reported and gets fixed probably in the next release. Why not.

For many years it was a reasonable assumption that any strange behaviour was an error in your code, not in MT4 or its compiler (...though that platform/compiler distinction is much larger now than it ever was before).

That assumption is no longer valid; anything odd now stands a very good chance of being an MT4/compiler bug. Under these new circumstances I think it makes sense to have as much visibility around bugs as possible.

I'd refer you back to a previous occasion where you say that you wasted several hours because of something which turned out to be an MT4 bug - https://www.mql5.com/en/forum/148327/page7#879879 - and which could potentially have been avoided by a post such as this one from ydrol.

 
gchrmt4:

For many years it was a reasonable assumption that any strange behaviour was an error in your code, not in MT4 or its compiler (...though that platform/compiler distinction is much larger now than it ever was before).

That assumption is no longer valid; anything odd now stands a very good chance of being an MT4/compiler bug. Under these new circumstances I think it makes sense to have as much visibility around bugs as possible.

I'd refer you back to a previous occasion where you say that you wasted several hours because of something which turned out to be an MT4 bug - https://www.mql5.com/en/forum/148327/page7#879879 - and which could potentially have been avoided by a post such as this one from ydrol.


Wow, guys, no problem, calm down. I did not want to start fire. My last post here.
 

Grrr - wasting my time ... looks like ServiceDesk is more interested in closing tickets than fixing issues...

Closed

Support Team 2014.03.14 07:36

MyClass is empty class

 
ydrol:

Grrr - wasting my time ... looks like ServiceDesk is more interested in closing tickets than fixing issues...

Closed

Support Team 2014.03.14 07:36

MyClass is empty class



Maybe if you provide code that make sense, it will be taken more seriously.
 

I always thought a good test case was to try to reduce down to the minimal code that reproduces the error.. esp when reporting compiler bugs.

So I just got frustrated that in taking the time to do so, it got closed without any real assessment.

It's perfectly fine and sensible to have empty classes - for example when subclassing... the base class might be empty.

Anyway, I did already re-submit the code with the change below. (not the comment though!) I hope it now makes it sensible enough for MQ to improve thier product. I hope it doesn't get closed because the Expert does not do anything...


// Dynamic Array of objects is leaked.
 
#property strict

class MyClass {
int notEmpty; // <<<<<<<<< added single member so object makes sense ?!
};

MyClass array[2];
MyClass single;

int OnInit()
  {
   return(INIT_SUCCEEDED);
  }

void OnDeinit(const int reason)
  {
  }

void OnTick()
  {
  }
Reason: