Erro interno

[cjp]

Entendi a questão das variáveis. Vou tentar consertar o programa.

Também li o anexo. Mas não entendi direito como resolver esta questão de o programa estar gravando informação na memória, onde ela não deveria entrar. Afinal, sempre achei que a gravação na memória fosse feita automaticamente pelo programa, sem intervenção do usuário ou mesmo do programador. O que eu estaria fazendo errado no programa para gravar em local onde não deveria entrar?

[bencz]

Oq acontece meu jovem, este erro já é erro na geração de código do compilador do harbour, ou mesmo na VM do harbour...
Bom, alguma coisa de muito grave está acontecendo em seus códigos, um dos grandes motivos, que venho a ver, é o seu alto uso de variaveis globais..., outro erro, pode ser um stackoverlfow
http://support.microsoft.com/kb/315937

Algum trecho de seu código da um increse tão grande em alguma variavel, que algum apontador do C, acaba requerindo mais memoria, e essa mais memoria acaba vindo de uma parte que é lock do sistema, e o windows da um estouro de exceção para o programa em execução, assim dando a exceção mostrada....
ou seja, conforme seu programa vai requerindo mais e mais memoria, o GC do harbour e a VM do harbour realiza um 'realloc' , vide links (
http://www.univasf.edu.br/~marcelo.lind ... /aula9.pdf ,
http://www.cplusplus.com/reference/cstdlib/realloc/ ) para poder armazenar oque você está pedindo para o programa armazenar, só que esse seu consumo de memoria se torna tão grande, que o programa vai jogando tudo p/ o stack interno da VM e esse stack interno da VM acaba por sua vez, tentando gravar alguma ifnormação em algum trecho de memoria do sistema, entendeu ? (:

[cjp]

Entendi sim, meu caro. Obrigado.

Como disse, estou tentando modificar o programa para reduzir o número de variáveis public. Mas essa não é uma tarefa fácil.

Teria como eu descobrir qual é a variável específica em que isso está ocorrendo, ou quais são as variáveis abertas no momento em que o erro ocorre, para eu resolver esta logo, resolvendo o problema, ao menos temporariamente?

[bencz]

complicado em, pode ser qualquer uma, vai depender de como está funcionando seu programa, e de como as informações estão transitando entre elas...

[alxsts]

Olá!

Por ora, não ocorreu mais. Se voltar a ocorrer (espero que não), eu posto novamente.

Espero que não ocorra. Se isso acontecer, vai parecer que o problema era mesmo na versão do Harbour ou do compilador C ou linkeditor que você usava.

De qualquer forma, é importante você se livrar das variáveis dos tipos PUBLIC e PRIVATE. Enquanto não faz isso totalmente, você pode descartá-las ao final de seu uso, em cada programa. Vou escrever um exemplo,no estilo antigo e usando essas variáveis. Mas não contem para ninguém:

Código: Selecionar todos

PROCEDURE Proc1

PARAMETERS p1, p2, p3   && essas variáveis são criadas como privadas

PUBLIC v1, v2, v3

   &&
   && Procedimentos
   &&

   ? v1  && .F.

   DO Proc2 WITH 5

   ? v1  && 10

   RELEASE p1, p2, p3, v1, v2, v3     &&  --->  Descarta as variáveis (libera da memória)

   hb_gcAll( .T. )   &&  --->  Força a execução do garbage collector do Harbour

   RETURN
*-------------------------------------------------------------------------------------------------------------------------------------------------------------------
PROCEDURE Proc2

PARAMETERS p1   && variável privada de Proc2

   v1 = p1 * 2

   RETURN

[bencz]

Correto, e, por maior interesse, você pode começar a re-escrever seu programa utilizando Orientação-a-objetos, mantendo seu programa 100000000000000% mais seguro e simples de se trabalhar

[bencz]

http://fivetechsupport.com/forums/viewt ... =6&t=19338

[Poka]

Olá a todos,

Alexandre,

Se eu tenho as rotinas A,B,C e D
a rotina A chama a B , e na B crio variáveis privadas. Até onde eu sei, ou achava que sabia, essas variáveis privadas tem valor se da rotina B eu ir para a C ou D.
Se eu voltar para a rotina A essas variáveis privadas, já não valem mais, então necessariamente eu não preciso executar um release.
Está correto isso?



Poka

[bencz]

Poka, desculpe-me, mas não entendi exatamente, o que você quis dizer...

Código: Selecionar todos

procedure exemplo1()
    local a, b, c, d
    exemplo2()
    return 

procedure exemplo2()
   local e, f, g, h
   e := 1
   f := 2
   g := 3
   h := 4
   return

Neste caso, as variaveis são realmente variaveis, que estão endereçadas em ESP, e quando eu crio uma variavel global, ela fica endereçada em um vetor, EAX, EBX ... assim, o edereço que fica 'permanente' para enquanto a execução do programa, enquanto, as variaeis locais são edereçadas em ESP e sub-escritas ou apagadas qnd você sai da função/metodo/rotina...

quando é declarada uma variavel global, algo do tipo é feito:

Código: Selecionar todos

; parametros em geral da função...
mov eax, [ebx+edi+<posição em pilha ou contador em pilha>] ; onde vai ficar endereçada a sua variavel global

e para o caso do stack:

Código: Selecionar todos

...
mov     eax, [esp+4]    ; variavel a
mov     ecx, [esp+8]   ; variavel b
mov     edx, [esp+12] ; variavel c
mov     ebx, [esp+16] ; variavel d
...

[alxsts]

Olá!

Exatamente Poka, você está correto. É assim mesmo que funciona a visibilidade das variáveis do tipo PRIVATE.

e eu voltar para a rotina A essas variáveis privadas, já não valem mais, então necessariamente eu não preciso executar um release.

É o que acontece com a variável p1 quando a rotina Proc2 é encerrada. Talvez o exemplo não tenha sido muito feliz mas, à vezes, é conveniente fazer um RELEASE e coleta de lixo durante a execução de uma rotina, antes de prosseguir com a mesma, principalmente após usar grandes arrays.

Para quem tiver vontade de ler, este artigo mostra boas práticas de programação Clipper, no que se refere ao gerenciamento da memória, e deve valer para Harbour e xHarbour também: CA-CLIPPER 5.x Memory Management

[cjp]

Lendo este artigo, encontrei dois pontos que poderiam me ajudar:

Monitor memory with //INFO.
When you start your CA-Clipper application with the //INFO option, CA-Clipper reports the condition of memory at the start of the application. The reports looks like this:

* DS=4F4E:0000 DS avail=30KB OS avail=255KB EMM avail=960KB
* DS= is the starting address of the DGROUP segment.
* DS avail=KB reports the amount of DGROUP available.
* OS avail=KB reports the amount of conventional memory available.
* EMM avail=KB report the amount of expanded memory allocated to the current application.

When the DS avail (DGROUP) is less than 15k at the start-up of an application, some large applications could experience stack eval errors at runtime. This number is arbitrary and your application may actually run just fine with less available DGROUP, however it is important that you monitor DS especially if your application uses third-party libraries or lots of LOCAL and STATIC memvars. It's always a good idea to make note of the amount of DS avail in your current application before and after you add new functions or libraries to the application. If you suddenly notice a dramatic decrease in DS avail after adding new code, then you should take note that you may be using a function from a library that uses excessive DGROUP.
Create a .MAP file.
Blinker supports a MAP= command that creates a map file with information about segment usage. This map file will show you which routines use DGROUP and exactly how much they consume.

No primeiro (//info), aparece:

Código: Selecionar todos

DS avail=1729200KB
OS avail=2077080KB
EMM avail=0KB
MemStat=Off
MT=Off

Entretanto, isso parece ser no início do programa, não tenho como ver a situação depois do uso das variáveis.

A outra opção (MAP file), que parece ser mais adequada para o que eu preciso, não sei como usar, nem o artigo ensina. Alguém saberia me ensinar?

[alxsts]

Olá!

Veja a função Memory().

[Poka]

Alexandre, BENCZ

Obrigado pelas explicações.

Realmente não tenho o costume de dar um release nas variáveis de memória, aliás um péssimo costume, diga-se de passagem, sempre defino as públicas no início do sistema , as locais, onde só devem valer nas rotinas específicas, as privadas ondes só devem valer naquela rotina e nas dependentes delas como por exemplo, numa entrada de materiais, onde uso um prg como browse, outro para os itens, outra para vencimentos, etc, então defino variavel private no prg do browse, e quando saio do browse não dou um release, e acontece ás vezes de nem declarar como private, aí altera uma variável já existente e fica que nem doido procurando erro. Realmente as declarações de variáveis são muito importantes no sistema.

Um abraço
`
Poka

[Jairo Maia]

Olá Inácio (cjp),

Com a versão 3.2.0 resolveu o problema? Se sim, por favor, nos informe.

Pergunto porque tenho uma situação que não foi possível usar a versão 3.2 porque a versão do Harbour 3.2 que tenho tem um bug com o comando SET CONFIRM ON, que em determinado momento que não consegui entender a razão trava o sistema ao usar o leitor de códigos e nem permite abrir o gerenciador de tarefas do Windows para encerrar. Então voltei para a versão 3.0 neste caso.

Porém, a versão 3.0 tem esse bug sim, ao abrir dois sistema em harbour ocorre o conflito de alocação de memória em determinado momento e aborta um deles. Como conheço como funciona o TAR2P, isso com certeza explica também o que ocorre comigo numa situação similar.

Afinal, sempre achei que a gravação na memória fosse feita automaticamente pelo programa, sem intervenção do usuário ou mesmo do programador.

Sim. E é assim mesmo. Mesmo no velho e guerreiro Clipper, ao trabalhar no modoprotegido é assim também. Quem aloca a memória é o sistema operacional.

[cjp]

Jairo, ainda estou testando, mas, de fato, desde que mudei para a 3.2, não aconteceu mais o erro nenhuma vez. Acho que realmente resolveu com a 3.2. Obrigado.