Mais um erro causado pela Microsoft

Mensagem por **JoséQuintas** » 05 Jul 2015 01:06

Antes de mais nada, estou postando aqui porque justamente aonde tenho erro é no uso relacionado ao Harbour.

É mais uma esquisitice da Microsoft.
Aqui tenho 8GB de memória, na grande maioria do tempo quase tudo disponível.
O erro é not enough memory for thread data

O que deu pra perceber é:
Tudo que é acessado no HD passa a fazer parte do cache, então cada vez tem mais memória em uso.
Quando faço cópia entre dois HDs, é aí que a coisa pega.
O erro vém depois, no uso do GIT ou geração/compilação do Harbour - no msvc.
Nesse caso, é reiniciar a máquina pra liberar a memória usada pelo cache.

Por pesquisa no google, o que encontrei é que foi criada uma nova função de API pra liberar memória.
Então se o programa chama a rotina antiga, pode não estar liberando memória suficiente.

Aqui um texto da Microsoft, mencionando a "nova" chamada de liberação de memória.

https://msdn.microsoft.com/en-us/library/d509d9f9.aspx

Se até o compilador C da Microsoft dá esse erro.... relatar o que pra quem?

Ainda bem que é eventual, e que já sei como resolver: reiniciando a máquina.

We recommend that an executable that calls the C run-time library (CRT) should use _beginthreadex for thread creation rather than the Windows API CreateThread. _beginthreadex initializes internal static storage used by many CRT functions in thread local storage. If you use CreateThread to create a thread, the CRT may terminate the process with R6016 when a call is made to a CRT function that requires initialized internal static storage.

Mensagem por **JoséQuintas** » 05 Jul 2015 01:34

Dei uma pesquisada nos fontes do Harbour.
Encontrei isto:

Código: Selecionar todos

#  if defined( HB_THREAD_RAWWINAPI )
      th_h = CreateThread( NULL, 0, start_func, Cargo, 0, th_id );
#  else
      th_h = ( HANDLE ) _beginthreadex( NULL, 0, start_func, Cargo, 0, th_id );
#  endif

Depois pesquisei HB_THREAD_RAWWINAPI e não encontrei em lugar nenhum.
Significa que, por padrão, o Harbour já faz a parte dele, já que para a primeira parte do IF acontecer, precisa disso definido em algum lugar.

Então... só resta reiniciar a máquina após acessar gigabytes de informação.

Mensagem por **Toledo** » 05 Jul 2015 08:28

JoséQuintas escreveu:Depois pesquisei HB_THREAD_RAWWINAPI e não encontrei em lugar nenhum.
... já que para a primeira parte do IF acontecer, precisa disso definido em algum lugar.

Foi definido no arquivo hbthread.h que está na pasta \INCLUDE do Harbour.

Depois este arquivo é incluído no thread.c :

Código: Selecionar todos

#include "hbthread.h"

Abraços,

Mensagem por **JoséQuintas** » 05 Jul 2015 09:48

Tem razão, esqueci dos arquivos H que atendem o C.
Depende de certas condições pra ativar/desativar.
E se entendi direito, a partir do msc 15.0 já usa do jeito novo.
Aqui uso do vs 2010, que é 16.0.

Poka · Mensagem por **Poka** » 05 Jul 2015 10:44

Olá,

Toledo, José Quintas
Esses comandos aí resolveria o problema da mensagem "PROGRAMA NÃO RESPONDENDO", me parece que é problema de memoria, no meu computador tenho só 2 g, mas tem empresa de 4 g que também acontece. Uso o Harbour versão 3.2.0 (r 1504082220).
Se não, vocês poderiam me dar uma luz para resolver isto.

Obrigado

Poka

Mensagem por **JoséQuintas** » 05 Jul 2015 14:15

Não tem a ver.
Às vezes essa mensagem é porque o programa entrou em LOOP, e não tem Inkey() dentro do loop.
Tipo... do while .not. eof(), enddo e esqueceu do skip.

rossine · Mensagem por **rossine** » 05 Jul 2015 16:38

Olá pessoal,

Há alguns dias eu também estou recebendo esta mensagem quando vou emitir uma nf-e:

not enough memory for thread data

Será que usando hb_gcall( .t. ) poderia resolver este problema ? ou teria alguma outra solução ?

Eu estou usando mingW32 e harbour 3.4.0.

Obrigado,

Rossine.

Mensagem por **JoséQuintas** » 05 Jul 2015 17:52

O que eu percebi é que tem a ver com memória cache.

Repare:
Mostra 5.6GB disponível, mas 1.5GB livre.
4.1GB está sendo usado como cache, e pode ser liberado a qualquer momento.
Quando acontece o erro aqui, a memória livre está bem baixa, e a usada como cache bem alta, geralmente após cópia de HD, ou durante a geração do Harbour onde tudo que é usado vai ficando em cache, ou durante o uso do GIT.

A impressão que tenho é que essa "liberação" depende da nova chamada.
E o erro é justamente quando está sendo usado multithread, coisa comum do GIT e default do Harbour 3.4.

Se fosse arriscar um chute, talvez algum parâmetro na chamada da função, ao invés de zero.

Mensagem por **JoséQuintas** » 05 Jul 2015 18:40

Como deixei de ser o único a ter o erro, relatei no Harbour.
Aqui o erro é eventual.
Talvez seja uma ocorrência nova pra 64 bits, com o Windows querendo tirar proveito de toda memória pra cache.

Mensagem por **JoséQuintas** » 05 Jul 2015 19:37

Rossine, relatei no Harbour e o Viktor pediu mais detalhes, incluindo situação, número do erro e texto exato do erro.

https://github.com/vszakats/harbour-cor ... -118670580

Vou tentar forçar o erro aqui, copiando HDs, atualizando Harbour, gerando Harbour, etc....

Mensagem por **JoséQuintas** » 05 Jul 2015 21:22

Ainda não consegui fabricar o erro.
Mas consegui usar muito cache.

5.5GB de memória disponível, mas mostrando 5MB de memória livre.

rossine · Mensagem por **rossine** » 06 Jul 2015 10:24

Olá José,

Eu reparei que o cache de minha máquina também está praticamente esgotada. Teve um momento que ficou no 0.

O erro que ocorre aqui, aparece uma janela do windows com estes dizeres:

Microsoft Visual C++ Runtime Library

Runtime Error!

Program: C:\Windows\Microsoft.NET\Framework\v2.0.50727\cvtres.exe

R6016
- not enough space for thread data

Vamos ver se o Viktor nos dá alguma dica sobre o que pode estar causando este problema.

Continuo procurando algo a respeito deste erro. Qualquer novidade lhe informo.

Obrigado,

Rossine.

Mensagem por **Kapiaba** » 06 Jul 2015 10:34

Bom dia Rossine, veja se ajuda:

https://support.microsoft.com/pt-br/kb/126709/pt

https://support.microsoft.com/en-us/kb/126709

http://forums.fivetechsupport.com/viewtopic.php?p=13301

Abs.

Mensagem por **JoséQuintas** » 06 Jul 2015 11:45

Achei estranho na sua mensagem mostrar a pasta do NET Framework.

No meu caso mostra como GIT.EXE ou CL.EXE, e acontece durante a geração do Harbour ou atualização dele.
Exatamente duas situações que fazem uso de multithread.

Como eu disse, aqui é eventual.
Nos meus testes forçados chegou a 0 de memória livre, e nem assim ocorreu o erro.

Pelo que entendi num dos links:
- Pode ser definido no programa principal, e reutilizado pelos módulos, sem limites, pois conta como 1 uso.
- Caso seja definido em cada módulo, cada módulo conta como 1, e tem limite.
- E caso um segundo programa utilize também para cada módulo, o limite para o segundo programa será menor.
- O limite só é zerado quando nenhum programa fizer uso desse arquivo, e ele for retirado da memória.
- E isso também pode estar relacionado a outras DLLs utilizadas pelo aplicativo, que fizerem referência a esse arquivo.

Resta identificar se o erro foi causado pelo Harbour, pelo aplicativo, ou por alguma dll adicional.

É o tipo de erro que começa conforme o aplicativo vai crescendo e usando mais recursos.

Me fez pensar do porquê inventaram o NET Framework: pra limitar todas as referências do aplicativo e DLLs a uma só.

rossine · Mensagem por **rossine** » 06 Jul 2015 13:46

Olá Kapiaba,

Nos links citados, fazem referência a uma função em c++, eu teria que inserir este código C++, dentro de minha aplicação ?

Obrigado,

Rossine.