Exceção ao Enviar NFCe

[Artsio]

Pude constatar através dos logs que houve alterações nessas funções de leitura do xml...

Para mim é essa  classe 

TACBrXmlDocument que está com algum problema

TACBrXmlDocument ?

[BigWings]

11 minutos atrás, Artsio disse:

Pude constatar através dos logs que houve alterações nessas funções de leitura do xml...

Sim, agora está sendo usada a libxml2.dll para a leitura dos XML, por a leitura ser muito mais rápida.

Talvez tenha algo errado no seu ambiente quanto a essa DLL.

[Artsio]

Qual era a dll anterior que estava sendo usada?

Pois pelo visto esta dll libxml2.dll tá dando problema com capicom.dll

pois o sistema nosso não funciona nem a pau com WinCrypt, e olha que já testamos em várias maquinas de clientes

foram mais de 10, e não funciona. Até assinamos na época o  ACBrPro e não foi de ajuda.

Poderiam ter deixado como configuração para retrocompatibilidade, porque agora ferrou de vez.

Tem mais de 400 notas pendentes de clientes...

 

[Artsio]

Qual a alternativa que vcs propõe, já por conta desse Bug, pois no meu projeto, limpei td do ACBr na máquina, dll, e recompilei e nada.

Continua dando esse problema de retorno vazio na NFCe, que internamente é um action violation ntdll.dll?

[BigWings]

Está em fase de migração das antigas units do PCN que fazem a leitura via código, para a libxml2.

Usando o programa exemplo do componente, o erro também ocorre?

[Artsio]

Aqui no nosso Sistema, as bpls e dlls, são todas carregadas dinamicamente, tem esse detalhe, pode ser por isso.

Só está ocorrendo na NFCe, os xml de retorno estão certo, voltando correto, mas por algum motivo não consegue

pegar os dados na leitura do xml de retorno. (CStats, Protocolo, estão vazios)

Se eu fechar a tela depois do erro, e abrir novamente e dar consulta, retorna o status e protocolo, correto.

Se tivesse uma função, por exemplo: "Refresh" no componente, ou algo assim para liberar da instância de memória os atributos que carregou a dll com violação de memória,

Daria para usar o consultar para pegar o retorno.

[BigWings]

4 minutos atrás, Artsio disse:

Aqui no nosso Sistema, as bpls e dlls, são todas carregadas dinamicamente, tem esse detalhe, pode ser por isso.

Pode ser, consegue gerar uma aplicação POC que demonstre o problema?

4 minutos atrás, Artsio disse:

Só está ocorrendo na NFCe, os xml de retorno estão certo, voltando correto, mas por algum motivo não consegue

No caso do ACBrNFe, está sendo usado o novo método apenas no modo síncrono, no assíncrono ainda é usado as units PCN.

5 minutos atrás, Artsio disse:

Se tivesse uma função, por exemplo: "Refresh" no componente, ou algo assim para liberar da instância de memória os atributos que carregou a dll com violação de memória,

Se tiver alguma sugestão de alteração no componente, faça e anexe no fórum, em um novo tópico de preferência.

Você não respondeu minha pergunta:

24 minutos atrás, BigWings disse:

Usando o programa exemplo do componente, o erro também ocorre?

 

[Artsio]

Não tive tempo de testar no exemplo, mas vou ver se consigo simular algo parecido com o nosso.

Testei no Síncrono e Assíncrono e também ocorre.

 

[Artsio]

Tem alguma ideia que possa estar testando se esta dll está sendo carregada?

Ou que possa estar fazendo para descubrir a origem do problema?

[BigWings]

4 horas atrás, Artsio disse:

Testei no Síncrono e Assíncrono e também ocorre.

Pelo programa exemplo do componente?

Vendo os fontes, no envio assíncrono não é usado a libxml2 para fazer a leitura dos XML de retorno, tanto do envio, retorno ou consulta de recibo. Porém é usada na consulta de protocolo.

1 hora atrás, Artsio disse:

Ou que possa estar fazendo para descubrir a origem do problema?

Primeira coisa é isolar o problema, usando o programa exemplo, ou criando uma aplicação pequena que demonstre o erro e disponibilizando os fontes aqui.

[Artsio]

Nos meus testes aqui consegui ver que está carregando a dll dinamicamente "libxml2.dll" na memória

Só quando vai chamar a função

"loadedDoc := xmlParseDoc(PAnsiChar(ansistring(AXmlDocument)));

dá o erro

15/08/2024 17:07:56: "TACBrXmlDocument.LoadFromXml" : Linha: 1351
15/08/2024 17:07:56: LibXml2File: C:\_ROTUMA\FGE\WIN32\libxml2.dll
15/08/2024 17:07:56: "TACBrXmlDocument.LoadFromXml" : Linha: 1356
15/08/2024 17:07:56: "TACBrXmlDocument.LoadFromXml" : Exception: Access violation at address 7728F953 in module 'ntdll.dll'. Write of address 00000014
15/08/2024 17:07:56: "TACBrXmlDocument.LoadFromXml" : Linha: 1384

procedure TACBrXmlDocument.LoadFromXml(AXmlDocument: string);
var
  loadedDoc: xmlDocPtr;
  loadedRoot: xmlNodePtr;
begin  LogSalvar('"TACBrXmlDocument.LoadFromXml" : Linha: 1351');
  // a linha abaixo foi comentada pois segundo o DSA consome muito a CPU e causa lentidão
//  AXmlDocument := NativeStringToUTF8(AXmlDocument);
  try
     LogSalvar('LibXml2File: '+LibXml2File);
     LogSalvar('"TACBrXmlDocument.LoadFromXml" : Linha: 1356');
     loadedDoc := xmlParseDoc(PAnsiChar(ansistring(AXmlDocument)));
     LogSalvar('"TACBrXmlDocument.LoadFromXml" : Linha: 1358');
  except on E: Exception do
     LogSalvar('"TACBrXmlDocument.LoadFromXml" : Exception: '+e.Message);
  end;

  if loadedDoc <> nil then
  begin  
    xmlFreeDoc(xmlDocInternal);
    xmlDocInternal := loadedDoc;

    loadedRoot := xmlDocGetRootElement(xmlDocInternal);
    if loadedRoot <> nil then
    begin
      xmlRootElement.Free;
      xmlRootElement := TACBrXmlNode.Create(Self, loadedRoot);
    end
    else
    begin
      raise EACBrXmlException.Create(xmlGetLastError()^.message);
    end;
  end
  else begin
    raise EACBrXmlException.Create(xmlGetLastError()^.message);
  end;
end;

 

[Victor H. Gonzales - Panda]

Bom dia,

a ntdll.dll isso é uma biblioteca externa, que pertence ao sistema operacional, não é da Suite ACBr, isso parece que está mais ligado a WincryptAPI do que com a LibXML2.

 

Algumas coisas precisam ser garantidas nos testes, como por exemplo o sistema operacional estar totalmente atualizado.

você colocou juntamente a aplicação as DLL da dependência da LibXML, OpenSSL de acordo com a arquitetura do seu sistema (x64, x32)?

LibXML2

p/acbr/code - Revision 34862: /trunk2/DLLs/LibXml2 (sf.net)

OpenSSL

p/acbr/code - Revision 34862: /trunk2/DLLs/OpenSSL/1.1.1.10 (sf.net)

e no programa exemplo ocorre a mesma situação?

[Felipe Govoni]

@Juliomar Marchetti demorei pra responder pois estava testando com o cliente, a tua dica não resolveu o problema. O que eu acho estranho é que o AV acontece eventualmente e somente se antes for feita uma venda com o TEF.

 

 

[Juliomar Marchetti]

50 minutos atrás, Felipe Govoni disse:

@Juliomar Marchetti demorei pra responder pois estava testando com o cliente, a tua dica não resolveu o problema. O que eu acho estranho é que o AV acontece eventualmente e somente se antes for feita uma venda com o TEF.

 

 

o problema está no inicializar e desinicilizar.

além de usar capicom junto com a dll por isso do AV

[Felipe Govoni]

pois é mas eu não uso capicom, tanto que não instalação do acbr esta marcado para não usar

e no componente estou usando:

 

[Juliomar Marchetti]

21 minutos atrás, Felipe Govoni disse:

pois é mas eu não uso capicom, tanto que não instalação do acbr esta marcado para não usar

e no componente estou usando:

 

tls é 1.2

incializa com a aplicação e só desicializa ao final?

não tem mais nada dentro de use algo de activex?

[Felipe Govoni]

inicializa com a aplicação e só desicializa ao final?

Se vc se refere ao TEF sim, inicializo quando abre o form do caixa

 

não tem mais nada dentro de use algo de activex?

Não (creio que não nem sei usar activex)

 

 

[Artsio]

Em 16/08/2024 at 09:37, Victor H. Gonzales - Panda disse:

Bom dia,

a ntdll.dll isso é uma biblioteca externa, que pertence ao sistema operacional, não é da Suite ACBr, isso parece que está mais ligado a WincryptAPI do que com a LibXML2.

 

Algumas coisas precisam ser garantidas nos testes, como por exemplo o sistema operacional estar totalmente atualizado.

Atualizei o sistema operacional

você colocou juntamente a aplicação as DLL da dependência da LibXML, OpenSSL de acordo com a arquitetura do seu sistema (x64, x32)?

Sim, ainda limpei td no sistema operacional, em referencia as essas dlls, e deixei td na pasta do exe. Ainda

garanti que estava linkando as dll libxml2.dll da pasta.

LibXML2

p/acbr/code - Revision 34862: /trunk2/DLLs/LibXml2 (sf.net)

OpenSSL

p/acbr/code - Revision 34862: /trunk2/DLLs/OpenSSL/1.1.1.10 (sf.net)

e no programa exemplo ocorre a mesma situação?

Estou extraindo e testando por fora

 

[Artsio]

Bom dia!

Depois de quebrar a cabeça a única maneira que consegui resolver foi 

editar o "ACBr_DFeComum" e acionar a função

"DestroyLibXml2Interface()" da interface "ACBrLibXml2.pas" que

libera a dll "LibXML2" da memória, nos "Destroy" das classes: "TACBrXmlDocument()" e "TDFeSSLXmlSignLibXml2";

 

Código que foi acrescentado:

Unit: ACBrDFeXsLibXml2:

destructor TDFeSSLXmlSignLibXml2.Destroy;
begin
   DestroyLibXml2Interface();
   inherited Destroy;
end;

 

Unit: ACBrXmlDocument:

destructor TACBrXmlDocument.Destroy;
begin
  if xmlRootElement <> nil then
    xmlRootElement.Free;
  if xmlDocInternal <> nil then
    xmlFreeDoc(xmlDocInternal);

  DestroyLibXml2Interface();
  inherited Destroy;
end;

 

Sei que o "DestroyLibXml2Interface()" já é chamado no finalization da unit "ACBrLibXml2".

Seja o que for por uso de thread, concorrência, as chamadas seguintes para o endereço

de memória dessa dll compartilhada estão dando violação de endereço memória,

e causam os retornos de leitura vazia do xml.

Talvez vcs poderiam criar um branch para com o carregamento estático dessa dll, para testar.

[EMBarbosa]

Em 03/09/2024 at 11:03, Artsio disse:

Sei que o "DestroyLibXml2Interface()" já é chamado no finalization da unit "ACBrLibXml2".

Essa sugestão, vai forçar a chamada de xmlCleanupParser sempre que utilizar um ACBrXMLDocument ou destruir um componente que use o TDFeSinglibXML2...

Pelo que entendi da documentação da libxml2, essa correção não deveria ser feita. Principalmente se a aplicação for multithread porque isso poderia levar a erros.

 

Essa função deveria ser chamada só quando estiver realmente descarregando a dll para encerrar a aplicação. Aqui o link:

 

https://gnome.pages.gitlab.gnome.org/libxml2/devhelp/libxml2-parser.html#xmlCleanupParser

 

Abaixo o aviso deles com grifo meu:

Citar

WARNING: if your application is multithreaded or has plugin support calling this may crash the application if another thread or a plugin is still using libxml2. It's sometimes very hard to guess if libxml2 is in use in the application, some libraries or plugins may use it without notice. In case of doubt abstain from calling this function or do it just before calling exit() to avoid leak reports from valgrind !

 

Seria muito importante para nós termos um executável mínimo que consiga reproduzir o problema.

[Warquia]

@EMBarbosa @Italo Giurizzato Junior Bom dia pessoal descobrir como gerar o erro.

O problema ocorre em configurações que optaram pelo uso do xsMsXml (legado) e em PCs independentes da versão do sistema operacional que não possuem o libxml2 no Windows. No ambiente Delphi\debug, o erro não acontece porque, com a instalação do ACBrInstall, as DLLs necessárias são copiadas para o PC. No entanto, ao definir o xsMsXml, o componente tenta carregar o libxml2 internamente. Por isso, ao reverter para a versão anterior do ACBr, tudo funciona corretamente. Acredito que o uso do xsMsXml deveria ser respeitado ou, pelo menos, essa opção deveria ser removida para que, na próxima compilação, o desenvolvimento seja forçado a utilizar o padrão atualizado da DLL. Dessa forma, evitamos erros difíceis de identificar.

[EMBarbosa]

2 horas atrás, Warquia disse:

@EMBarbosa @Italo Giurizzato Junior Bom dia pessoal descobrir como gerar o erro.

Muito obrigado pelo retorno. Ótima investigação.

2 horas atrás, Warquia disse:

Acredito que o uso do xsMsXml deveria ser respeitado ou, pelo menos, essa opção deveria ser removida para que, na próxima compilação, o desenvolvimento seja forçado a utilizar o padrão atualizado da DLL. Dessa forma, evitamos erros difíceis de identificar.

Se você tiver alguma sugestão de alteração no código relacionado a isso por favor, compartilhe conosco.

[EMBarbosa]

Em 06/09/2024 at 09:18, Warquia disse:

@EMBarbosa @Italo Giurizzato Junior Bom dia pessoal descobrir como gerar o erro.

O problema ocorre em configurações que optaram pelo uso do xsMsXml (legado) e em PCs independentes da versão do sistema operacional que não possuem o libxml2 no Windows. No ambiente Delphi\debug, o erro não acontece porque, com a instalação do ACBrInstall, as DLLs necessárias são copiadas para o PC. No entanto, ao definir o xsMsXml, o componente tenta carregar o libxml2 internamente. Por isso, ao reverter para a versão anterior do ACBr, tudo funciona corretamente. Acredito que o uso do xsMsXml deveria ser respeitado ou, pelo menos, essa opção deveria ser removida para que, na próxima compilação, o desenvolvimento seja forçado a utilizar o padrão atualizado da DLL. Dessa forma, evitamos erros difíceis de identificar.

@Artsio @Felipe Govoni, etc...

Fiz um commit relacionado a esse caso com a ideia de levantar uma exception mostrando na mensagem de erro a falta da LibXML2.

https://sourceforge.net/p/acbr/code/35504/

Favor reportar qualquer problema.

[Warquia]

20 horas atrás, EMBarbosa disse:

@Artsio @Felipe Govoni, etc...

Fiz um commit relacionado a esse caso com a ideia de levantar uma exception mostrando na mensagem de erro a falta da LibXML2.

https://sourceforge.net/p/acbr/code/35504/

Favor reportar qualquer problema.

@EMBarbosa Muito obrigado.
Infelizmente, não pude colaborar mais com o caso, pois estou participando de diversos eventos nesses meses fora da minha base de trabalho.