Fuga de memória - ACBrNFeWebServices (complemento)

[Cezinha Anjos]

Olá pessoal!

Eu encotrei uma fuga de memória na unit ACBrNFeWebServices.

A mesma acontece aproximadamente na linha 1129, onde o objeto ReqResp nunca é liberado quando usa-se capicom.

A correção seria:

    {$IFDEF ACBrNFeOpenSSL}

       HTTP.Free;

    {$ELSE}

      ReqResp.Free;

    {$ENDIF}

Segue em anexo a unit corrigida caso achem interessante fazer o merge. Me parece que o método "Executar" é bastante utilizado. Agradeço se alguém puder checar. Muito obrigado e peço desculpas por algum transtorno. ================================== Olá pessoal! Eu encontrei diversas outras fugas em ACBrNFeWebServices.pas. Segue neste post a unit corrigida. O problema é basicamente o mesmo citado no post anterior. ACBrNFeWebServices.pas Peço atenção nas linhas (do arquivo original) 1703 e 1816. O

1703: NFeRetorno := TRetConsSitNFe.Create;

1816: //NFeRetorno.Free;

Passei a linha para antes do try e descomentei a linha 1816. Acho que alguém já havia comentado por ter passado por algum problema. Acredito que a mudança de posição da linha 1703 deve resolver o problema.

Agradeço se minhas considerações forem consideradas relevantes, pois acredito que estas fugas podem degradar o aplicativo.

Muito obrigado

[André Ferreira de Moraes]

O componente sempre chamava o método ReqResp.Free, mas foi passado por um usuário do componente um link da embarcadeiro falando que não era necessário chamar este método pois o objeto era liberado automaticamente.

Infelizmente não lembro nem o nome do usuário e nem o link que continha essa informação.

Sobre a linha 1816: //NFeRetorno.Free ela não ira fazer com que o usuário não tenha acesso aos retornos do webservice?

[Cezinha Anjos]

Olá?!

Em primeiro lugar em agradeço por ter dado atenção ao meu post. Vamos lá as minhas considerações:

Problema 1:

O objeto abaixo é um descendente de TComponent. Para ele ser destruído automaticamente ele teria que ter um owner. Este owner é passado no construtor. Atualmente está sendo passado como nil. Por favor, veja abaixo a implementação da linha 1674

1674: ReqResp := THTTPReqResp.Create(nil);

Particularmente, em ocasiões onde o objeto é usado somente em um método específico (como é o caso do método TNFeConsulta.Executar) eu prefiro criar sem o owner e eu mesmo controlar o ciclo de vida do objeto. Desta maneira eu consigo deixar o meu código mais legível, pois sei que o escopo daquele objeto é local. Vamos supor ainda que eu decida fazer algo como abaixo:

1674: ReqResp := THTTPReqResp.Create(self);

Neste caso eu estaria atrelando a vida do meu objeto ao tempo de vida da instância de TNFeConsulta (não estou entrando aqui em detalhes do tipo... TNFeConsulta também deveria ser do tipo TComponent para permitir esse tipo de coisa).

Se eu chamasse o método TNFeConsulta.Executar três vezes, por exemplo, eu teria três novos objetos desnecessários na memória até TNFeConsulta ser destruído.

Eu poderia ainda sugerir uma refatoração maior, no qual evitaria esse tipo de coisa, mas por momento optei por sugerir apenas os .free pois imaginei que a aceitação seria mais fácil.

Não quero e nem tenho direito em desmerecer o trabalho que foi feito até aqui. Pelo contrário, sou muito grato por poder usar uma suite de componentes tão boa e de graça. Por isso não fique brabo comigo

Problema 2:

Posso estar enganado, mas eu não vi nenhum ponto de saída do método que transporta para fora dele a referência do objeto NFeRetorno.

Eu percebi que ele é usado apenas localmente.

Se houvesse a necessidade de algum agente externo utilizar a referência de NFeRetorno eu sugeriria fazer uma inversão de controle para que o "utilizador" ficasse com a responsabilidade de criar e destruir o NFeRetorno. Mas honestamente eu não consegui encontrar isso no código. Portanto, acredito ser seguro aplicar o .free nele.

As fugas que eu apontei foram detectadas utilizando o FastMM. Eu rodei diversas vezes nossos códigos e fui isolando cada uma. O FastMM não faz nada automático, mas ajuda bastante. Foi uma tarde dura de trabalho... hehehe.

Eu não sei se consegui ser claro em minhas explicações, mas me coloco a disposição para detalhar ainda mais se for necessário.

De ante-mão eu gostaria de parabenizar pelo projeto. Gostaria de poder contribuir com trabalho para o mesmo. Se precisarem fazer alguma refatoração eu me disponho. Conheço e aplico um pouquinho de orientação a objetos e padrões de projetos. Contem comigo se eu puder ser útil.

Aguardo ansiosamente o retorno.

[Cezinha Anjos]

Olá Sr. André! Tudo bem? Espero que sim...

Conseguiu dar uma olhadinha no problema relatado?

Eu vi que tem um outro tópico aberto do ACBrNFeMonitor no qual o mesmo gera um Access Violation em uma condição específica. Não sei se os problemas são correlacionados, mas me parecem estar.

Há algo mais que você precise que eu possa fazer para aplicar a correção?

Muito obrigado

[André Ferreira de Moraes]

Ainda não tive tempo de testar suas alterações, sobre o ReqResp.Free sei que não teremos problemas pois já estavam nos fontes do componente e foram retirados por sugestão de algum usuário, preciso testar apenas a sugestão sobre o NFeRetorno.Free.

Assim que testar envio para o SVN e posto informações aqui neste tópico.

[André Ferreira de Moraes]

Estava analisando suas alterações e vi que após o finally o objeto NFeRetorno já está sendo liberado(Linha 1839), portanto acho q não é necessário descomentar a linha 1816.

Já enviei suas alterações para o SVN, obrigado pela colaboração.

[Cezinha Anjos]

Olá?!

Desculpe... na realidade eu havia passado o número da linha do //NFeRetorno.Free;. Eu deveria ter passado o número da linha do que estava dentro do finally. No arquivo que eu enviei para o merge eu havia descomentado a segunda linha

A versão que eu tenho aqui os dois //NFeRetorno.Free; estavam comentados. Talvez alguém já tenha encontrado o problema antes da gente.

Obrigado pela ajuda e reafirmo que estamos a disposição caso necessitem alguma implementação.