Download MetaTrader 5
To add comments, please log in or register
Publish your article and thousands of people all over the world will read it!
ydrol
593
ydrol 2014.03.13 02:18 

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)

Ovo Cz
3049
Ovo Cz 2014.03.13 05:31  
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.
ydrol
593
ydrol 2014.03.13 10:09  
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...

gchrmt4
356
gchrmt4 2014.03.13 11:00  
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.)
Ovo Cz
3049
Ovo Cz 2014.03.13 12:19  
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.
ydrol
593
ydrol 2014.03.13 12:51  
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.

gchrmt4
356
gchrmt4 2014.03.13 13:17  
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.

Ovo Cz
3049
Ovo Cz 2014.03.13 14:39  
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.
ydrol
593
ydrol 2014.03.14 15:15  

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

Alain Verleyen
Moderator
30299
Alain Verleyen 2014.03.14 15:57  
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.
ydrol
593
ydrol 2014.03.14 16:17  

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()
  {
  }
/ /12
To add comments, please log in or register