Errors, bugs, questions - page 2571

 
What does the expert log warning mean, after the script is finished?
2 leaked strings left

How can this be fixed?
Translator translates, two leaked strings on the left. But it's not clear what's on the left, the string?

The script usesJAson library.
A Json string is received from dll via memcpy_s, in dll this string has type const wchar_t*
In #import parameter of exported function, declared asstring & str, that is by reference, and string itself is declared asstring str;
Then string str is deserialized

js.Deserialize(str); 

The problem is exactly deserialisation of the incoming string from memcpy_s.

Since if you create a json check string in the script

string str = "{\"s\":\"1000\"}";

then the warning message doesn't appear.
Deserializing a string from dll, the warning message appears again after the script finishes, 2 leaked strings left

I tried to convert string to char array StringToCharArray, and deserialize char array.
But the problem persists, and 2 leaked strings left appears.
What may be the reason for this?

 
From the dll I tried to explicitly passthe check json string
L"{\"s\":\"1000\"}"
The
2 leaked strings leftwarninghas disappeared.
It turns out that a function in the dll that reads network data causes this behavior.

But I don't understand the interpretation of
2 leaked strings left, what exactly it means andwhere to dig further?
 
Roman:
From the dll I tried to explicitly passthe check json string
The
2 leaked strings leftwarninghas disappeared.
It turns out that the function in the dll reading network data causes such behavior.

But I don't understand the interpretation of
2 leaked strings left, what does it mean exactly andwhere to dig further?

If translated loosely, then: "2 lines cause a memory leak".

Literally, it means about this: 2 current strings left.

 

in the latest build of mt4 in the tester iHigh,iTime functions do not work for thereim frames above the daily frame

iHigh(NULL,PERIOD_W1,0) = 0
iTime(NULL,PERIOD_W1,0) = NULL


 
Artyom Trishkin:

If translated loosely, then: "2 lines cause a memory leak".

And literally, it's like this: 2 current lines are left.

What's interesting, when I get a Json string and without deserializing it I output it to the comment, as is, there's no leakage.
When I start deserializing to get Json string element, it starts leaking.
It's not clear, is the library leaking...

 
Roman:

What's interesting, when I get a Json string and without deserializing it I output it to the comment, as is, there is no leakage.
When I start deserializing to get Json string element, it starts leaking.
I don't know if the library is leaking...

It's leaking. Memory for strings is allocated, bytes are copied, but memory is not cleared.

Got the source code?

Kudos to developers for memory manager to keep track of this.

 
Vladimir Simakov:

It is leaking. Memory for strings is allocated, bytes are copied, but memory is not cleared.

Do you have the source code?

Kudos to developers for the memory manager to keep track of this.

The library seems to call Clear () in the Deserialize class method;

virtual bool Deserialize (string js, int acp = CP_ACP)
{
   int i = 0;
   Clear ();
   CJAVal::code_page = acp;
   char arr [];
   int slen = StringToCharArray (js, arr, 0, WHOLE_ARRAY, CJAVal::code_page);
   return Deserialize (arr, slen, i);
}

I got the source code from here.

 
Roman:

The library calls Clear () in the Deserialize class method;

The source code was taken from here.

The leak is not there, but most likely in that dll, from which you get the string.

 
Roman:

It looks like in the library, in the method of the Deserialize class, Clear () is called;

I got the source code from here.

How do you create CJVal? Probably new CJVal()?

The leak is not there, but most likely in that dll, from which you get the string.

It is unlikely that the terminal catches this.
 
Vladimir Simakov:

The leak is not there, but most likely in the dll from which you get the string.

I also get the impression that the function that reads the data is leaking.
It buffers the data first, then transfers it, and after the transfer, the buffer is cleared, according to the lib developer.
But it seems that there is a bug in buffer clearing.
But what is interesting, if we don't deserialize the string in the script, there is no leak, i.e. the problem occurs at the moment of deserialization in the script.
Just checking different variants of possible causes.
No source code unfortunately, as the .lib is closed.

Reason: