Newsgroup: it.comp.lang.perl
Titolo: Strano problema script perl/cgi

Salve,
per un lavoro ho creato un semplice script che, presi alcuni dati da
una form html (il cui codice non c'entra con lo script in questione),
genera un file pdf che viene conservato sul filesystem ed inviato via
fax attraverso HylaFAX. Il form, a sua volta, è popolato con dati in
parte presi da un database che risiede su un altra macchina.
La soluzione e` stata sviluppata su Debian GNU/Linux (unstable, a
causa della necessita` di alcuni software, estranei alla parte perl) e
gira attraverso Apache2/mod_perl, facendo uso dei seguenti moduli:
* CGI.pm (3.10);
* PDF::API2 (0.46);
* Fax::Hylafax::Client (1.01).
Il problema con cui mi ritrovo a combattere consiste nel fatto che,
alle volte, il pdf risulta compilato con dati che non c'entrano un
fico secco con quelli inviati dall'utente attraverso la form. La cosa
non sembra essere legata a situazioni di stress del sistema, avviene
anche quando vi sono pochi utenti ad utilizzarlo (2 o 3).
Mi sembra quasi come se l'istanza di CGI.pm attraverso la quale
ottengo i dati passati tramite POST contenga dati differenti rispetto
a quelli inviati dall'utente, eppure ottengo l'oggetto nel "main"
dello script istanziandolo ogni volta con "my $cgi = new CGI;".
Altra cosa curiosa e' che in un caso del genere, se provo a fare post
un paio di volte, ottengo il documento corretto.
Ogni suggerimento e` graditissimo, poiche' la cosa mi sta
letteralmente facendo perdere il sonno.
Grazie,
dds

 [...]
Posso solo suggerire qualche strategia d'indagine, data la scarsezza di 
informazioni.
1.
 > * CGI.pm (3.10);
Quasi certamente non è questo il problema, ma passare a CGI 3.11 (se ti 
è possibile) certamente non può far male (e se fa male si può sempre 
tornare indietro).
2.
Esegui la tua applicazione in ambiente cgi /liscio/ (non mod_perl né 
altro ambiente persistente) e vedi se il problema scompare.
Se sì, molto probabilmente il problema è dovuto a qualche variabile 
persistente non correttamente deallocata: in genere la cosa si risolve 
con use strict che a sua volta rivela la magagna.
3.
Cerca di isolare il problema, cioè elimina l'elaborazione del PDF a 
valle e fatti soltanto stampare i parametri della form che pervengono 
alla tua applicazione.
Un modo immediato per ispezionare i parametri consiste nel cambiare il 
metodo della form da POST a GET, e guardare direttamente nel browser la 
query-string appesa alla URL (posto che a seguito dell'invio dei dati 
venga generata una pagina di risposta senza redirect).
4.
Se i dati della form che pervengono alla tua applicazione sono ogni 
volta corretti, allora (probabilmente) mod_perl non c'entra niente ed il 
problema risiede a valle, probabilmente in una qualche race-condition o 
mancata finalizzazione dei file generati su disco.
(In questo caso il problema non dovrebbe verificarsi con un unico utente 
che genera richieste sufficientemente distanziate...)
Se il problema è questo, in genere si risolve attribuendo ai file 
generati nomi *unici* (cosa che si può ottenere inserendo l'id ed 
eventuali altri parametri di sessione nel nome del file) o gestendo 
esplicitamente dei lock sui file condivisi.
Buona fortuna.
Ciao,
Emanuele.

  >>>>> Emanuele Zeppieri writes:
[...]
  >> * CGI.pm (3.10);
  EZ> Quasi certamente non è questo il problema, ma passare a CGI 3.11
Ci proverò.
  EZ> Esegui la tua applicazione in ambiente cgi /liscio/ 
Proverò anche questo.
  EZ> Se sì, molto probabilmente il problema è dovuto a qualche
  EZ> variabile persistente non correttamente deallocata: in genere la
  EZ> cosa si risolve con use strict che a sua volta rivela la
  EZ> magagna.
Uso sempre strict come filosofia di vita con perl e nel caso specifico
l'error.log non mi ritorna problemi.
  EZ> Cerca di isolare il problema, cioè elimina l'elaborazione del
  EZ> PDF a valle e fatti soltanto stampare i parametri della form che
  EZ> pervengono alla tua applicazione.  Un modo immediato per
  EZ> ispezionare i parametri consiste nel cambiare il metodo della
  EZ> form da POST a GET, e guardare direttamente nel browser la
  EZ> query-string appesa alla URL (posto che a seguito dell'invio dei
  EZ> dati venga generata una pagina di risposta senza redirect).
Questa e` una cosa che ho gia' fatto ed in tutte le mie prove non ho
ottenuto errori: ottenevo quello che mandavo tramite post.
  EZ> Se i dati della form che pervengono alla tua applicazione sono
  EZ> ogni volta corretti, allora (probabilmente) mod_perl non c'entra
  EZ> niente ed il problema risiede a valle, probabilmente in una
  EZ> qualche race-condition o mancata finalizzazione dei file
  EZ> generati su disco. (In questo caso il problema non dovrebbe
  EZ> verificarsi con un unico utente che genera richieste
  EZ> sufficientemente distanziate...)
Il sospetto e` che il caso sia questo; in genere tali errori mi
accadono quando si è almeno in due ad utilizzare il sistema. Tuttavia,
se per "finalizzazione dei file" intendi la chiamata finale ad un
metodo close(), allora non so piu' cosa dire, poiche' faccio
attenzione a chiudere correttamente i file generati.
  EZ> Se il problema è questo, in genere si risolve attribuendo ai
  EZ> file generati nomi *unici* 
...e lo sono, la struttura e`: ragione_sociale-data_ora.pdf
  EZ> o gestendo esplicitamente dei lock sui file condivisi.
provero' anche con questo.
Visto che utlizzo il modello prefork di apache2, oggi, prima di
lasciare, ho provato ad aumentare il numero di processi attivi di
apache (e conseguentemente anche quelli di riserva), inoltre,
spulciando i log ho notato qualche segmentation fault, ma dovevo andar
via e non ho approfondito.
  EZ> Buona fortuna.
Mi servira'.
Grazie dei suggerimenti,
Nico.