Erros, bugs, perguntas - página 2571

 
O que significa o aviso de registo do perito, depois de o guião estar terminado?
2 leaked strings left

Como é que isto pode ser corrigido?
O tradutor traduz, duas cordas vazadas à esquerda. Mas não está claro o que está à esquerda, a corda?

O guião utiliza a bibliotecaJAson .
Uma string Json é recebida da dll via memcpy_s, na dll esta string tem o tipo const wchar_t*.
Em #importar parâmetro da função exportada, declarado comostring & str, isto é, por referência, e a própria string é declarada comostring str;
Depois o cordel é deserializado

js.Deserialize(str); 

O problema é exactamente a deserialização do fio recebido do memcpy_s.

Uma vez que se criar uma cadeia de verificação json no guião

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

então a mensagem de aviso não aparece.
Deserializando uma string da dll, a mensagem de aviso aparece novamente após o script terminar, restam 2 strings com fugas

Tentei converter corda para matriz de caracteres StringToCharArray, e deserializar a matriz de caracteres.
Mas o problema persiste, e aparecem 2 fios que sobraram.
Qual poderá ser a razão para isto?

 
A partir da dll tentei passar explicitamenteo cheque json string
L"{\"s\":\"1000\"}"
Os
2 fios vazados doaviso defuga de fios desapareceram.
Acontece que uma função na dll que lê dados da rede causa este comportamento.

Mas não compreendo a interpretação de
2 fios que sobraram, o que significa exactamente eonde cavar mais?
 
Roman:
A partir do dll, tentei passar explicitamenteo cheque json string
Os
2 fios que sobraram doaviso defuga desapareceram.
Acontece que a função na rede de leitura de dados dll causa tal comportamento.

Mas não compreendo a interpretação de
2 fios que sobraram, o que significa exactamente eonde cavar mais?

Se traduzido vagamente, então: "2 linhas causam uma fuga de memória".

Literalmente, significa sobre isto: 2 cordas de corrente restantes.

 

na última construção do mt4 no testador iHigh, as funções do iTime não funcionam para frames acima do frame diário

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


 
Artyom Trishkin:

Se traduzido vagamente, então: "2 linhas causam uma fuga de memória".

E, literalmente, é assim: restam 2 linhas actuais.

O que é interessante, quando recebo uma corda Json e sem a deserializar, dou-a ao comentário, como é, não há fugas.
Quando começo a deserializar para obter o elemento de corda Json, ele começa a vazar.
Não está claro, é a biblioteca a vazar...

 
Roman:

O que é interessante, quando recebo uma corda Json e sem a deserializar, dou-a ao comentário, tal como é, não há fugas.
Quando começo a deserializar para obter o elemento de corda Json, ele começa a vazar.
Não sei se a biblioteca tem fugas...

Está a verter. A memória para as cordas é atribuída, os bytes são copiados, mas a memória não é apagada.

Tem o código fonte?

Kudos aos programadores para que o gestor de memória se mantenha a par disto.

 
Vladimir Simakov:

Está a verter. A memória para as cordas é atribuída, os bytes são copiados, mas a memória não é apagada.

Tem o código fonte?

Kudos aos programadores para que o gestor de memória acompanhe isto.

A biblioteca parece chamar Clear () no método Deserialize class;

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);
}

O código-fonte foi-me fornecido por aqui.

 
Roman:

A biblioteca chama Clear () no método Deserialize class;

O código fonte foi retirado daqui.

A fuga não está lá, mas muito provavelmente nessa dll, da qual se obtém a cadeia de caracteres.

 
Roman:

Parece que na biblioteca, no método da classe Deserialize, Clear () é chamado Clear ();

O código-fonte foi-me fornecido por aqui.

Como se cria CJVal? Provavelmente CJVal() novo?

A fuga não está lá, mas muito provavelmente nessa dll, da qual se obtém a cadeia de caracteres.

É improvável que o terminal apanhe isto.
 
Vladimir Simakov:

A fuga não está lá, mas muito provavelmente na dll da qual se obtém a cadeia de caracteres.

Também tenho a impressão de que a função que lê os dados está a vazar.
Primeiro, guarda os dados, depois transfere-os, e depois de transferidos, o tampão é limpo, de acordo com o criador da biblioteca.
Mas parece que há um bug na limpeza do buffer.
Mas o que é interessante, se não deserializarmos a corda no guião, não há fuga, ou seja, o problema ocorre no momento da deserialização no guião.
Basta verificar as diferentes variantes das causas possíveis.
Infelizmente, nenhum código fonte, porque o .lib está fechado.