Newsgroup: it.comp.lang.visual-basic
Titolo: L'applicazione ha eseguito un'operazione non valida e verrà terminata.

ciao
Come da oggetto, chiedo il vostro aiuto.
Ho tre applicativi installati dal medesimo cliente (identici, stessa
versione)
Uno funziona bene.
Uno ogni 2 giorni si inchioda con il messaggio fatidico in subject
L'altro ogni 2-3 ore, stesso messaggio
I programmi gestiscono dei dispositivi ethernet (si tratta di software
di telecontrollo industriale), e sono installati su 3 PC identici,
appena usciti di fabbrica, con gli stessi software e lo stesso hw.
Cambiano solo il numero di dispositivi collegati via ethernet: 4 nel
primo, 8 nel secondo, e 8 nel terzo.
In base alla vs esperienza, quali sono i punti critici da verificare
quando succedono questi errori?
Ho un archivio di log scritto in mdb che mi avvisa su tutto quello che
succede alla macchina. Escludo con certezza quindi che sia colpa
dell'operatore: quando succede la macchina è inutilizzata.
La colpa potrebbe essere di qualche procedura che si attiva con alcuni
timer, anche se, guardando il codice, mi sembrano tutte "pulite".
sperando in un vostro aiuto...
ciao
Marco F.

Caro Marco,
mi sa che il problema dipende dall'esaurimento della memoria.
Il sospetto deriva dal fatto che il primo PC con meno dispositivi connessi 
non si blocca (o probabilmente se lo si lasciasse funzionare per molti 
giorni consecutivi anche lui darebbe lo stesso problema)
Per provare che è questo, dovresti monitorizzare la quantità di memoria che 
usa il programma oppure, in modo molto empirico, diminuire la memoria RAM 
installata: se il problema è questo, il PC si bloccherà come gli altri due.
Se fossi in te, controllerei la corretta chiusura delle Sub o delle Function 
o dei gruppi Do-Loop all'interno di esse: il problema potrebbe essere 
riconducibile ad un problema di esaurimento di memoria per lo Stack (catasta 
operativa).
Oppure ancora potrebbe essere un problema di Garbage Collection (la fase di 
recupero gestita dal sistema operativo per le aree di memoria non più 
utilizzate) che viene fatta in momenti critici di scrittura della memoria da 
parte del tuo programma: questo problema sarebbe più "tosto" in quanto, a 
quanto so,
non si può in XP forzare la GC.
La soluzione potrebbe essere quella di ogni tot ore di resettare il PC o 
quanto meno il programma: certo se il ciclo di produzione è continuo, 
potrebbe non essere possibile.
E' anche possibile che siano degli OCX forniti con i dispositivi Ethernet 
che non funzionano bene (non sarebbe la prima volta!): in questo caso, se 
puoi, eliminali e fatti una procedura per conto tuo.
Spero di esseri stato utile.
Ettore Massimo Albani

 Spero di esseri stato utile.
Moltissimo
Grazie ancora per il tempo che mi hai dedicato in questa esauriente
risposta.
Ciao
Marco F.

Caro Marco,
la Garbage Collection è simile alla procedura di Defrag che si effettua su 
HD per recuperare i cluster di memoria non più utilizzati ed anche un 
avvicinamento dei cluster appartenenti allo stesso file.
Più che altro il problema deriva dalle variabili stringa e tutte le 
variabili che possono occupare una memoria variabile da 1 a n byte. Non sono 
interessate dal fenomeno le variabili che occupano sempre la stessa quantità 
di memoria (ad esempio quelle numeriche, di data, booleane, ecc.)
Supponiamo, infatti, di assegnare alla variabile stringa Z una stringa
Z = "ABDCEFG"
a livello di memoria questo significa che è stata assegnata una area della 
RAM contenente la stringa, mentre alla variabile Z sarè assegnato il 
relativo puntatore (semplificando, in realtà la cosa è più complicata).
Quando riassegniamo a Z un'altro valore
Z="ABCDEFGHIJKL"  oppure "ABCD"
il sistema si limita a fornire a Z un nuovo puntatore ed assegnare una nuova 
area di memoria per la stringa.
E' evidente che dopo tot assegnazioni, molta memoria conterrà le vecchie 
stringhe che però non sono più utilizzate: ecco che interviene il Sistema 
per recuperare le aree perse (garbage alla lettera significa rifuto e 
Garbage Collection quindi vuol dire raccolta del rifiuto)
Ora questa procedura porta via tanto più tempo quanto più iterazioni sono 
state fatte e, quando si attiva, impedisce alle altre procedure di accedere 
alla memoria RAM.
Mi ricordo che in DOS e con BASIC 7 ho risolto la questione forzando la GC 
ogni tot ore, ma questo pare non si possa fare con XP che gestisce anche lo 
swap della RAM con l'HD.
Quindi non credo che avresti un giovamento dichiarando globalmente le 
variabili stringa, anzi forse il contrario (le variabili locali vengono 
distrutte con la chiusura della Sub o della Function).
Magari riduci il numero di variabili utilizzate nella stesso environment, 
questo sì potrebbe essere d'aiuto (ma purtroppo il problema verrebbe solo 
procrastinato).
Comunque, visto che gli OCX avevano un bug proprio sulla memoria, mi 
orienterei su quelli per risolvere il problema
Ettore Massimo Albani 

 quantità di memoria (ad esempio quelle numeriche, di data, booleane, ecc.)
Se il problema sono risorse non rilasciate credo che lo si stia affrontando 
da un punto di vista errato.
Prima di tutto occorre capire se parliamo di vb6 o 
vb.net
.
In VB6 il GC entra in azione immediatamente quando una variabile esce dallo 
scope recuperando tutta la memoria utilizzata.
In VB.Net il GC entra in azione quando ha tempo e voglia o è costretto dal 
fatto che il sistema ha bisogno di risorse non più utilizzate.
Però il concetto non cambia molto: se c'è memoria sprecata questa viene 
recuperata.
Il problema sono le risorse "unmanaged", cioè quelle non gestite da VB (o 
dal Fw), ad es. chiamate a funzioni dell'API che allocano memoria: questa 
deve essere rilasciata esplicitamente dal programmatore poichè il GC non 
sapendo come agire su di essa lascia tutto così com'è.
Ciao