Errors, bugs, questions - page 786

[Valerii Mazurenko]

Uh, something was messed up in the latest build. .ex5 of one of the indicators has grown in size by almost 10 times compared to the .ex5 compiled by the previous build. Well, it is not a problem. But an error appeared when drawing the indicator (before entering its parameters):

2012.07.27 02:53:57     MP2012_GRI (EURUSD,M30) Access violation read to 0x000000003FF39D25

I've already fixed 3\4 code. And if I again comment out a little bit, I'll get it (together with error above):

2012.07.27 02:56:42     Custom Indicator        'MP2012_GRI' may work incorrectly, as it requires more than 256Kb of stack memory

and it really doesn't work

And if I again comment out a bit the code, the first two errors disappear, but I get them when unloading the indicator:

2012.07.27 02:47:35     MP2012_GRI (EURUSD,M30) 9 leaked strings left

(Numbers may be different - depends on how much code I've commented out)

I found out beforehand, that my function is too big by volume - I'll beat it on small functions.

...and everything was fine in the last build

[Renat Fatkhullin]

notused:

Uh, something was messed up in the latest build. .ex5 of one of the indicators has grown in size by almost 10 times compared to the .ex5 compiled by the previous build. Well, it is not a problem. But an error appeared when drawing the indicator (before entering its parameters):

I've already fixed 3\4 code. And if I'll change it a little more, I'll get (together with error above):

We have tightened control over the sandbox environment for the sake of better security.

The message about the stack tells you that you have used more than 256 kilobytes of stack in one of your functions, which is a serious problem in programming. For instance, in C/C++ using a local stack function even for 16Kb is considered a serious warning.

You probably allocate a lot of static arrays in functions, for example:

void func(void)
  {
   double arr1[128000];
   double arr2[128000];
   double arr3[128000];

  }

You must not do that.

If you need large arrays, use dynamic arrays better. For example:

double ExtArr[];

void func(void)
  {
   double arr1[];
   double arr2[];

   ArrayResize(ExtArr,128000,0);
   ArrayResize(arr1,128000,0);
   ArrayResize(arr2,128000,0);
  }

[Valerii Mazurenko]

Renat:

We have tightened control over the sandbox environment for the sake of increased security.

The message about the stack tells you that you have used more than 256 kilobytes in one function of the stack, which is a serious issue in programming. For instance, in C/C++ using a local stack by even 16 kb in a function is considered a serious warning.

You probably allocate a lot of static arrays in functions, for example:

You should not do that.

If you need large arrays, use dynamic arrays instead. For instance:

I don't use static arrays at all in this indicator; I don't pass anything heavier than int in functions, etc. But you actively use all sorts of graphical functions.

For example,

   ObjectSetString(0, stmp, OBJPROP_TEXT, "HB");
   ObjectSetInteger(0, stmp, OBJPROP_COLOR, hbColor);

If the last line is commented out, everything is fine. The problem is that there are a lot of such calls and this one

ObjectSetInteger(0, stmp, OBJPROP_COLOR, hbColor);

is the 20th or 30th in a row.

I think the problem lies in the size of the function, since commenting the code avoids the problem, while most of the code consists of ObjectSetXXX. I've found out through experiments that breaking it into smaller parts is useless too - an aggressive inliner will still pile everything up and generate errors. I can try to put out more code, but I'll do it tomorrow. The service desk is also tomorrow, if we don't figure it out earlier.

[Renat Fatkhullin]

notused:

I don't use static arrays at all in this indicator; I don't pass anything heavier than int into functions, etc. But all sorts of graphical functions are actively used.

But there is something huge, isn't there?

For example, include a local copy of a class which just has a ton of static arrays in its members. That's usually where the deposits of local stack consumers hide.

For example,

If the last line is commented out, everything is fine. The problem is that we have a lot of such calls and this one

is the 20th or 30th in a row.

I think the problem is in the size of the function, since commenting the code avoids the problem, and most of the code consists of ObjectSetXXX. I've found out through experiments that breaking it into smaller parts is useless too - an aggressive inliner will still pile everything up and generate errors. I can try to put out more code, but I'll do it tomorrow. Service Desk also tomorrow, if we don't figure it out before.

Divide up functions, stack into classes.

Inliner most likely has nothing to do with it - it doesn't insert too large pieces of code. Especially if they are heavy/lots of local variables.

[Valerii Mazurenko]

Renat:

But there is something huge, isn't there?

For example, include a local copy of a class which just has a ton of static arrays in its members. That's usually where the deposits of local stack consumers are hiding.

Divide up functions, stack into classes.

Inliner probably has nothing to do with it - it doesn't insert too big chunks of code. Especially if they have heavy/lots of local variables.

Service Desk #444495

[yucc Kalina]

Why is it like this ? sloppy payout or what ! only 1 agent earned 1 kr and 0.3 kr was paid per day !

[Aleksey Rodionov]

Be sure to write to servicedesk with these headers:

Terminal version and bit rate

...

Problem description

...

Sequence of actions ...

...

Result obtained ...

...

Expected result ...

...

Additional information ...

...

Or can you put it in your own words?

[TheXpert]

Zeleniy:

or can you put it all in your own words?

A list would be better. This will make life a lot easier for whoever is dealing with the bug.

[---]

Zeleniy:

Do you have to write to servicedesk with these headings?

or can I do it in my own words?

you can do it all in your own words, but

Terminal version and bit rate
Problem description
Action sequence
Result obtained
Expected result

necessarily.

------------

You are not writing an essay on a free subject, you are writing a text for a developer who should quickly understand what you want from him without any details.

[Aleksey Rodionov]

sergeev:

you can do all of your own, but

Terminal version and bit rate
Problem description
Action sequence
Result obtained
Expected result

necessarily.

------------

You are not writing an essay on a free subject, you are writing a text for a developer who should quickly understand what you want from him without any details.

I chose the section Site mql5.com and the proposal and now I don't understand how to attach it to the headings.