Errors, bugs, questions - page 2759

 
Bug in MT5 debugger (build 2450) incorrect triggering of manually set breakpoints:
void test(){
   if(false){
      int i = 1;      // вручную установленная точка останова
   }   
}                     // место срабатывания точки останова при отладке

void OnStart(){
   test();   
}


UPD:
Thanks for the criticism, went back to original project and highlighted the problem encountered without over-optimization of the code:
class A{
public:
   bool m_flag;
   A* m_next;
   A(bool flag) : m_flag(flag){}
   
   void test(){
      if(m_flag){
         printf("1");
         m_next = m_next;    // Вручную установленная точка останова срабатывает как для false так и true условий
         //m_next = &this;   // Ok
      }   
   }
};

void OnStart(){
  {A a(false); a.test();}   // Result: breakpoint              Expected result: 
  {A a(true);  a.test();}   // Result: printf + breakpoint     Expected result: printf + breakpoint
}
 
Sergey Dzyublik:
Bug in MT5 debugger (build 2450) incorrect triggering of manually set breakpoints:

Can you please explain why you have to go through all this trouble?

if(false)
Do you use debugger?
 
Sergey Chalyshev:

Can you please explain why we have to twist the code like this?

Do you use debugging?

The code shows a BAG where the condition cannot be entered, but the breakpoint still triggers in a completely different place in the code.
More questions?

 

Wrote the following message to the discovery support.

Tested the robot on a story. Got some strange results. The bottom part of the table is on the screenshot. If you consider that I trade with 100,000 rubles, the negative balance of -6049 with 17% drawdown seems unbelievable. Indeed, when I openthe chart testing this set of parameters, I get a positive balance at the specified drawdown. The account is real 75287 (as seen in the photo). What may be the reason for such behavior of the program?

I can also add that all parameter sets behave in this way.

Got the answer:

Unfortunately, such issues are not in the scope of technical support.

Please contact the developers of the terminal.

What could be the reason?

 
Sergey Dzyublik:

The code shows a BAG where a condition cannot be entered, but still triggers a breakpoint in a completely different place in the code.
More questions?

Everything seems right to me. The program ignores if(false) and triggers at the nearest code fragment).

 
TraSer:

It seems to me that everything is correct. The program ignores if(false) and triggers at the closest place in the code).

This is not correct at all. If I need to stop only when a condition is met and the stop is on every tick, I'll go crazy while...

 
Sergey Dzyublik:

Any other questions?

what makes you think that the compiler didn't throw away the text of if(false) condition {....} when compiling the project ?

a breakpoint appears on the first ME text character of the rest of the code because ME can't shift strings, foldings and other VS wonders

ME can't analyze code in real-time, at most autosubstitutions are available

although if it's a bug, it's a bug

 
Igor Makanu:

what makes you think that the compiler didn't throw away the text of the if(false) condition {....} when compiling the project ?

the breakpoint was at the first ME text character of the rest of the code because ME can't shift strings, foldings and other VS wonders

ME can't analyze code in real time, at most autosubstitutions are available

but if it's a bug, it's a bug.

You have to test it with a normal condition. I got this the other day: when executing code step by step

  if(desiredProfit > 0 && summProfit > desiredProfit)
   {
    CloseAllPosition();
    DeleteAllPending();
    openSeries = Should_I_open;
    return;
   }

in the debugger, with an explicit condition not being met, function calls were not executed, but return; is. I decided that since there is no more code after the curved bracket and there is only one more curved bracket terminating void OnTick(), the compiler has moved return

 
Alexey Viktorov:

This should be tested with a normal condition.

Yes, that's what I'm talking about, not false, but something like:

int i=1;
if(--i == 0)...

usually the compiler doesn't see such a condition when compiling

 
Thanks for the critique, went back to the original draft and highlighted the problem encountered without over-optimising the code:
class A{
public:
   bool m_flag;
   A* m_next;
   A(bool flag) : m_flag(flag){}
   
   void test(){
      if(m_flag){
         printf("1");
         m_next = m_next;    // Вручную установленная точка останова срабатывает как для false так и true условий
         //m_next = &this;   // Ok
      }   
   }
};

void OnStart(){
  {A a(false); a.test();}   // Result: breakpoint              Expected result: 
  {A a(true);  a.test();}   // Result: printf + breakpoint     Expected result: printf + breakpoint
}
Reason: