[Risolto] Run Error (216) - General protection fault

[petrusic]

Guardando il codice mi sembra manchi la properties msg alla form di attesa.

Si, con tutte le prove ed i tentativi fatti per aggiungere una Form di Attesa, ho cancellato il campo msg. Ora l'ho ripristinato, ma non cambia niente.

L'errore sembra dovuto a file residui sul disco.
Suggerisco di cancellare qualche .o e .pp e riprovare la compilazione.

Ma così, a caso?

Ho dato una guardata alla directory relativa ai file.o ed visto una marea di file. Andare ad individuare quelli giusti mi sembra un'impresa. Così, a polso, potrei cancellare

/home/petrus/.lazarus/units/x86_64-linux/gtk2/componentpalette_options.o
/home/petrus/.lazarus/units/x86_64-linux/gtk2/componentpalette.o
/home/petrus/.lazarus/units/x86_64-linux/gtk2/componentlist.o

mentre degli innumerevoli file.pp trovasti quelli che mi sembrano strettamente legati a Lazarus sono

/usr/share/lazarus/2.2.6/components/fpreport/design/fpreportdesignreportdata.pp
/usr/share/lazarus/2.2.6/components/fpreport/design/fpreportdesignobjectlist.pp
/usr/share/lazarus/2.2.6/components/fpreport/design/fpreportdesigner.pp
/usr/share/lazarus/2.2.6/components/fpreport/design/fpreportdesignctrl.pp

Purtroppo, per la mia scarsa conoscenza di Lazarus, non mi sento di avventurarmi ad intraprendere percorsi a me assolutamente ignoti.

[Stilgar]

Pardon .. non PP ma PPU, mi son perso una lettere mentre scrivevo.
Ad occhio e croce pp sono i sorgenti. (uso .pas come estensione, per abitudine).
Eventualmente Lazarus permette di fare la "clean up and build" da menu.
Così non si incorre in errori di cancellazione.
Si presenta una finestra di conferma (così si vede cosa verrà pulito e ricompilato)


Fa tutto Lazarus.


Stilgar

[Stilgar]

@slapshot
[/size]
Pompa dei messaggi è il mio modo di descrivere il meccanismo che permette di inviare messaggi alle applicazioni.
Come sistema operativo e anche come applicazione.


Il sistema operativo conosce le finestre che ha visibili.
Se nascondi tutte le finestre e liberi il desktop, poi selezioni l'applicazione che ti interessa, il sistema operativo manda dei messaggi per riattivare le finestre che devono essere visualizzate.
Lazarus rimappa questi messaggi, nel caso d'esempio LM_SHOW (vado a memoria, potrei ricordare male la costante)
Internamente viene fatto il routing del messaggio verso la finestra interessate che riceva il messaggio. TForm gestiste tutto questo in modo trasparente.
Se crei la finestra fuori dal contesto applicativo, hai si la form attiva e visibile, ma in caso di "Update" o metodi legati ai messaggi da so/app, potresti avere comportamenti non attesi. Devi controllare tutto tu. Anche l'aggiornamento.


E' corretto, lecito e intelligente, non creare 150 form, di cui al massimo solo 1 o due sono attive contemporaneamente, 150 sono veramente tante. Basta creare e distruggere in modo corretto le istanze. Stiamo parlando di un caso limite però.


Lazarus creata di default tutte le form. Quando crei una nuova form dal designer, aggiunge il codice per la creazione. Il pattern comportamentale proposto è questo.


Le TForm sono classi "particolari" che hanno bisogno di qualche attenzione in più. 


Il design a messaggi, è utilizzato anche da SDL (videogiochi/multimediale). Giusto per non sembrare Winzozo oriented.


Stilgar.

[petrusic]

Eventualmente Lazarus permette di fare la "clean up and build" da menu.
Così non si incorre in errori di cancellazione.
Si presenta una finestra di conferma (così si vede cosa verrà pulito e ricompilato)
Fa tutto Lazarus.

Purtroppo non riesco a seguirti al volo.

Se ho capito bene la tua indicazione, il menù di cui parli è quello riportato come allegato, solo che lì dentro i file .o e .ppu non sono riportati secondo la propria dipendenza dal progetto principale, quindi io potrei soltanto cancellare gli unici file che riesco a riconoscere (frmattesa.o e frmattesa.ppu).

[Stilgar]

Volendo potresti cancellare solo quei due file.
Se il compilatore ti indica form8 e quella variabile non esiste più, magari è un'altra la unit che non viene aggiornata. Per il "refactory" in genere si usa il Crtl+Shift+E . Ci pensa lazarus a cambiare i nomi delle classi/variabili per te e le dovrebbe modificare tutte. Uso "dovrebbe" perché ogni tanto mi scazza.
Prendi i file intermedi (o e ppu) e cancellali tutti. Così sei sicuro che non ci siano problemi.
Tanto il compilatore li ricrea in poco tempo.


Giusto per fare la prova.


Stilgar.

[petrusic]

Volendo potresti cancellare solo quei due file.
Se il compilatore ti indica form8 e quella variabile non esiste più, magari è un'altra la unit che non viene aggiornata. Per il "refactory" in genere si usa il Crtl+Shift+E . Ci pensa lazarus a cambiare i nomi delle classi/variabili per te e le dovrebbe modificare tutte.

Non ho eseguito il Crtl+Shift+E, perchè ho capito  che quello si occupa solamente della ricostruzione, mentre io dovevo ripulire e ricostruire.

Sono entrato dall'IDE in Esegui -> Ripulire e costruire e dentro le finestre "Cartelle sorgenti del pacchetto" ho selezionato solamente "*.ppu;*.o;", quindi ho premuto il pulsante "Ripulisci e Costruisci".

dopo la ricostruzione è partita in automatico la compilazione e:
L'Errore sulla Form8 è scomparso, mentre erano rimasti gli altri.

Guardando meglio dentro la Form9, in cui si trovano le righe:

Codice: [Seleziona]

  Application.CreateForm(TFormAttendi, FormAttendi);
  FormAttendi.msg:= 'Ricerca   MOVIMENTI AMMORTIZZABILI  in corso' + lineending + lineending + '-----  A T T E N D I  -----';
  FormAttendi.Show;  

e mi sono accorto che fra gli uses mancava il nome del file FrmAttendi. Ho provveduto allora ad inserirlo ed a ricompilare.

La compilazione si è completata senza errori. Ora, però è l'esecuzione a segnalare un Errore, quello riportato come allegato.

Sembra che debba usare il costruttore CreateNew, ma io non trovato niente del genere.

[slapshot]

Probabilmente ha sempre a che fare con le risorse della form:

TCustomForm.Create raises an exception if resource is not found
Reason: Each form created by the IDE should have a resource, so if resource is not found there is something wrong with either a resource or the unit which contains the faulty form. Therefore the application should inform the developer that the form can't function correctly without the resource. This change is also Delphi compatible and compatible with TFrame and TDataModule components.
Remedy: If you need a resourceless form you have 3 options:
Create a TForm class (not a descendant)
Construct your form using the CreateNew() constructor.
It is also possible to disable the exception by setting the global variable RequireDerivedFormResource to False.

Prelevato da qui: https://wiki.lazarus.freepascal.org/Lazarus_1.0_release_notes#TCustomForm.Create_raises_an_exception_if_resource_is_not_found:

Però a questo punto cercherei di mettere ordine nel progetto e nel numero delle form e unit da usare.

[petrusic]

Niente da fare. NON funziona!

Ho chiuso Lazarus  e poi ho riavviato.

L'Errore sulla Form8 è ricomparso.
  e 

[nomorelogic]

nel messaggio di errore c'è scritto che non trova il file .lfm di quel form
puoi verificare la presenza?

[slapshot]

Niente da fare. NON funziona!

Ho chiuso Lazarus  e poi ho riavviato.

L'Errore sulla Form8 è ricomparso.
  e 

Ci fai anche uno screenshot della dir dove sono contenuti i file di unit ed i relativi .lfm ? Ricordati che sotto Linux c'è differenza tra maiuscole e minuscole, probabilmente deve essere un problema del genere. Se disegni la form tramite la IDE di Lazarus, necessariamente deve esserci il .lfm .

[petrusic]

nel messaggio di errore c'è scritto che non trova il file .lfm di quel form
puoi verificare la presenza?

Mi dispiace, ma non sono più in condizione di farlo. Ho eliminato tutto ed ho ricreato la Form8 come default.
Chiedo vivamente scusa a tutti, ma mi sono ... stancato.
Va bene così.

[DragoRosso]

.... ma mi sono ... stancato.

Non prendertela, ci vuole molta pazienza per programmare.

E più "vai avanti" con la programmazione, che diventa più complessa, e più pazienza ci vuole.
Quando c'è un problema, o presunto tale, occorre munirsi di santa pazienza e pian piano procedere alla ricerca della causa, senza però mettere in atto cambiamenti radicali.

Alle volte, come hai fatto, però ricostruire una data "cosa" da zero è una soluzione efficacie.
Sotto Linux tieni presente, come accennavano altri partecipanti al topic, che maiuscolo / minuscolo vengono gestiti in maniera differenziata e che quando si fanno delle operazioni di "RIDENOMINAZIONE" si possono avere effetti collaterali non indifferenti (ma d'altronde anche in Windows se si rinominano file con nomi simili ... e si dimentica qualche vecchio nome in qualche uses ...).

Banalmente quando salvi una UNIT con la sua FORM, o li rinomini, una scrittura del nomefile con maiuscolo / minuscolo non corretto e non conforme a quanto inserito nelle uses (a mano) può generare problemi come quelli che hai verificato tu.

Ciò a maggior ragione se magari rimane qualche "rimasuglio" di file compilato (tipo .o oppure .ppu) che corrisponde a quanto erratamente ancora presente nelle uses.

Sinceramente non sò il compilatore di FPC come si comporta precisamente, ma tutti i compilatori usano dei meccanismi di "hashing"e di cache basati molto spesso sulle date di modifica dei file per velocizzare la compilazione, per cui quando si rinomina una unità potrebbe essere che  rimangano i file vecchi compilati (che non vengono cancellati perche il sorgente non esiste più e quindi il compilatore non sà nemmeno che esiste il vecchio compilato) che se richiamati dal programma generano errori.

In pratica, quando tu inserisci il nome di una unit nelle USES, il compilatore cerca o il file .PAS o il file .PP o il file .PPU (poi ovviamente c'è anche tutta una serie di file collegati ...). Se non esistono file .PAS o .PP ma solo il .PPU e per il compilatore il file è valido, questo viene usato. E il .PPU senza .PAS (riferiti a file del tuo progetto, non a quelli di sistema o di altri di terze parti) è molto probabile che sia un residuo  che ti darà quei problemi.

Spero di avere chiarito la probabile situazione in cui ti sei venuto a trovare (e non sei solo).

[petrusic]

E più "vai avanti" con la programmazione, che diventa più complessa, e più pazienza ci vuole.
Quando c'è un problema, o presunto tale, occorre munirsi di santa pazienza e pian piano procedere alla ricerca della causa, senza però mettere in atto cambiamenti radicali.

Tutta la pazienza che un vecchio programmatore, come me può mettere, ha sempre un limite e stare una settimana appresso ad un problema legato ad una scelta non necessitata, diventa pesante ed ha superato ogni limite di sopportazione.

Mi sarebbe piaciuto modificare il nome mnmonico della Form per intuirne al molo lo scopo nel futuro, quando avessi bisogno di sfruttarne l'utilizzo in altri programmi, ma credo di non avere ancora capito qualche meccanismo nell'ingranaggio logico dell'impiego di una Form.

Alle volte, come hai fatto, però ricostruire una data "cosa" da zero è una soluzione efficacie.
Sotto Linux tieni presente, come accennavano altri partecipanti al topic, che maiuscolo / minuscolo vengono gestiti in maniera differenziata e che quando si fanno delle operazioni di "RIDENOMINAZIONE" si possono avere effetti collaterali non indifferenti.

Anche tu mi fai presente una peculiarità di Linux che ho appreso ed assimilato venti anni fa. Questa riflessione nei miei confronti è alquanto irrispettosa. Vi salva soltanto il fatto di non conoscere la persona con la qualke state dialogando.

Banalmente quando salvi una UNIT con la sua FORM, o li rinomini, una scrittura del nomefile con maiuscolo / minuscolo non corretto e non conforme a quanto inserito nelle uses (a mano) può generare problemi come quelli che hai verificato tu.
Ciò a maggior ragione se magari rimane qualche "rimasuglio" di file compilato (tipo .o oppure .ppu) che corrisponde a quanto erratamente ancora presente nelle uses.
Sinceramente non sò il compilatore di FPC come si comporta precisamente, ma tutti i compilatori usano dei meccanismi di "hashing"e di cache basati molto spesso sulle date di modifica dei file per velocizzare la compilazione, per cui quando si rinomina una unità potrebbe essere che  rimangano i file vecchi compilati (che non vengono cancellati perche il sorgente non esiste più e quindi il compilatore non sà nemmeno che esiste il vecchio compilato) che se richiamati dal programma generano errori.
In pratica, quando tu inserisci il nome di una unit nelle USES, il compilatore cerca o il file .PAS o il file .PP o il file .PPU (poi ovviamente c'è anche tutta una serie di file collegati ...). Se non esistono file .PAS o .PP ma solo il .PPU e per il compilatore il file è valido, questo viene usato. E il .PPU senza .PAS (riferiti a file del tuo progetto, non a quelli di sistema o di altri di terze parti) è molto probabile che sia un residuo  che ti darà quei problemi.
Spero di avere chiarito la probabile situazione in cui ti sei venuto a trovare (e non sei solo).

Ecco, questo concetto è sicuramente prezioso, perchè formativo e ti ringrazio moltissimo.
 

[slapshot]

Anche tu mi fai presente una peculiarità di Linux che ho appreso ed assimilato venti anni fa. Questa riflessione nei miei confronti è alquanto irrispettosa. Vi salva soltanto il fatto di non conoscere la persona con la qualke state dialogando.

Ciao, non devi prendertela per questo. Dietro un forum siamo tutti più o meno sconosciuti, i nostri background sono relativi e, a volte, le cose più semplici sono quelle che sfuggono, proprio come modificare il nome delle form da Lazarus. Facendolo da terminale, magari, sarebbe stato più lampante. Oppure il file .res che non si trova più ecc..

[DragoRosso]

Anche tu mi fai presente una peculiarità di Linux che ho appreso ed assimilato venti anni fa. Questa riflessione nei miei confronti è alquanto irrispettosa. Vi salva soltanto il fatto di non conoscere la persona con la qualke state dialogando.

Non era mia intenzione offenderti o essere irrispettoso in alcun modo. Ciò che ho commentato è a favore di chiunque legga, altrimenti non ha senso che esista il forum. Le cose devono essere dette e ripetute, affinchè chiunque possa prenderne spunto.
Ciao