[Gfoss] Fwd: scienza e stregoneria (was minidump alla chiusura di Qgis...)

Ven 18 Set 2015 11:20:07 CEST

Mi permetto di inoltrare (e ribadire) le parole di Furieri, a proposito del
minidump.

Inoltre, questo bug è stato già inserito da me nella lista del problemi
bloccanti di QGIS:

http://hub.qgis.org/issues/13272

Forse non è chiaro a tutti il problema.  Oppure, devo pensare che sia
invece molto noto a tutti e allora ho le seguenti ipotesi, dato che si
parla di soldi:

Ipotesi 1 )   "Lo struzzo"  fa finta di non vedere

Ipotesi 2 )   "Lo str..zo"   mette un bug   e aspetta  di pescare

C'è qualche altra ipotesi ?

A presto

Roberto

---------- Messaggio inoltrato ----------
Da: <a.furieri a lqt.it>
Date: 5 settembre 2015 11:54
Oggetto: [Gfoss] scienza e stregoneria (was minidump alla chiusura di
Qgis...)
A: gfoss a lists.gfoss.it

On Sat, 5 Sep 2015 09:34:21 +0200, Luca Mandolesi wrote:

> Si parla di una macchina con windows 8 e un database in
> spatialiate....che su quella macchina al copia e incolla crasha... il
> fatto è che su altra macchina la stessa operazione col medesimo
> database non crusha al copia e incolla ma lo fa nel momento in cui si
> fanno "certi" passaggi nel gestore di stili. Il problema è che
> l'errore non è riproducibile è qui che mi areno, a volte lo fa altre
> no...quindi speravo in sto benedetto file di dump di trovare
> spiegazioni.
>
>
Luca,

un "bug pazzo" di questo tipo non e' affatto un oggetto misterioso
(almeno in linea di principio); alla radice c'e' sempre una causa
assolutamente razionale e riproducibile, solo che e' dannatamente
difficile da identificare correttamente, e quindi puo' date l'erronea
impressione di un problema "indemoniato" del tutto caotico.

sintomi assolutamente tipici:
- gira "quasi sempre" bene, ma ogni tanto mi va in crash nelle
  situazioni piu' disparate e senza nessuna logica apparente.
- su Linux gira perfettamente, invece su Windows mi va in crash
  (ma puo' accadere facilmente anche l'opposto)
- ho svariati PC Windows assolutamente identici: su molti gira bene,
  ma su un paio mi va regolarmente in crash.
- l'ho usato tranquillamente per un mese, non ho aggiornato nulla,
  eppure da ieri ha iniziato ad andare frequentemente in crash
- etc etc etc

non e' l'unica spiegazione possibile, ma molto spesso (quasi sempre)
si finisce con lo scoprire che la causa reale per tutta questa
disparata collezione di errori apparentemente misteriosi ed
assolutamente inspiegabili e' una ed una sola.

QUEL SOFTWARE CONTIENE VARIABILI NON INIZIALIZZATE

senza entrare in troppi dettagli tecnici, una variabile non
inizializzata e' potenzialmente nefasta perche' al momento
del run-time puo' assumere qualsiasi valore arbitrario in
modo assolutamente casuale.
ma non finisce qua: una singola variabile non inizializzata
puo' innescare facilmente una lunga catena di eventi molto
ramificata ed assolutamente imprevedibile, per cui magari il
crash finisce con l'avvenire in qualche punto che apparentemente
non sembra avere nessun legame diretto con la criticita' iniziale
che ha scatenato l'inferno.

tutto questo in fondo spiega bene perche' gli effetti pratici
possono essere cosi' variegati e fantasiosamente disparati;
dare la caccia al sintomo in questo caso e' sostanzialmente
inutile, perche' il legame tra causa ed effetto e' dettato
esclusivamente dal caso (cioe' dai valori assolutamente
arbitrari e casuali presenti in memoria al momento del runtime).
evidentemente la soluzione "vera" e' una sola: arrivare ad
identificare esattamente dove, come e perche' si viene a
creare una condizione di variabile non inizializzata.
e molto spesso questo e' uno dei task di debugging piu'
rognosi e piu' difficili da risolvere.

se poi si tratta di un software che usa intensivamente il
multithreading la situazione puo' facilmente diventare un
vero e proprio incubo, perche' gli errori logici dovuti alle
variabili non inizializzate possono intrecciarsi in modo
perverso con ulteriori errori dovuti a cattiva sincronizzazione
tra i vari threads che stanno girando in parallelo, fino a
creare le situazioni piu' assurde e meno verosimili.

se questo e' il contesto (e nota bene: se ...), analizzare
il memory dump e' assolutamente inutile: perche' quel dump
e' semplicemente una fotografia statica della memoria al
momento del crash, ma non ti dira' assolutamente nulla su:
- eventuali errori avvenuti in precedenza causa mancata
  inizializzazione delle variabili.
- eventuali errori dovuti a cattiva sincronizzazione tra
  i vari threads.

facciamo conto che sia un giallo: il medico legale potra'
dirti facilmente che la vittima e' morta perche' aveva una
pallottola esattamente in mezzo al cervello.
ma non potra' mai arrivare a capire se quella pallottola
e' stata sparata per motivi passionali, per mafia, per
rapina, per terrorismo o magari per uno sventurato incidente
assolutamente involontario.
tutto questo tocca al detective scoprirlo ;-)

possibili soluzioni (e ruolo attivo delle communities)
---------------------------------------------------------
lamentarsi "mi va in crash in modo incomprensibile e casuale"
evidentemente serve a poco; ok, fa scattare un vago segnale di
allarme, ma e' troppo generico per potere sperare di innescare
qualche intervento risolutivo in modo realmente utile.

invece fortunatamente molti utenti sono in grado di compilarsi
autonomamente l'applicazione a partire dai sorgenti.
in genere chi fa queste attivita' tira semplicemente ad arrivare
fino in fondo con il minore sforzo possibile, ma cosi' facendo si
perdono occasioni preziose per contribuire utilmente allo sviluppo
del proprio progetto preferito.
basterebbe semplicemente attivare sempre il massimo livello diagnostico
supportato dal compilatore e quindi dedicare una decina di minuti
alla attenta lettura di tutti i warnings riportati dal compilatore,
compresi (soprattutto) quelli di piu' infimo rango.
molto verosimilmente ci troverete alcune interessanti segnalazioni
relative all'uso di variabili potenzialmente non inizializzate
ed altri analoghi pasticcetti (capita, e pure spesso: e non e'
detto che non possa sfuggire all'attenzione degli sviluppatori)
ma non finisce qua: un gran numero di utenti significa anche un
gran numero di compilatori differenti (gcc, msvc, clang etc) e di
versioni differenti: spesso accade che un determinato compilatore
riesca ad identificare condizioni critiche che invece sfuggono ad
altri; fare tante compilazioni indipendenti con diagnostica estesa
significa arrivare con poco sforzo ad un codice assolutamente
pulito e quindi piu' robusto.
naturalmente poi vi dovrete prendere il (piccolo) disturbo di
segnalare agli sviluppatori tutti i "pasticciotti" che vi e'
sembrato di identificare, fornendo tutti gli elementi utili
per la loro identificazione.
gli sviluppatori adorano questo tipo di segnalazione, ci vanno
a nozze e baceranno commossi la terra sotto ai vostri piedi :-D

l'altra possibile linea di intervento riguarda invece l'uso
sistematico di analizzatori dinamici di memoria come p.es. Valgrind.
qua andiamo un po' piu' sul complesso, e sicuramente serve un
certo livello di skill tecnico (ma non vi spaventate, nulla
di realmente impossibile, basta un pizzico di predisposizione,
un po' di tempo libero e soprattutto buona volonta').
Valgrind e' perfettamente in grado di gettare piena luce su molti
errori di memoria non inizializzata, e molto spesso riesce pure
a beccare gli errori di sincronizzazione tra thread concorrenti.
mettere in piedi una sessione di test su Valgrind per una app
complessa come QGIS porta via un sacco di tempo (lunghe ore ...):
e per arrivare ad interpretare correttamente un Valgrind-report
serve sicuramente intelligenza e molta esperienza (e tempo ...);
ma e' anche vero che tanti testers che lavorino in parallelo ed
in modo indipendente possono velocemente arrivare a sviluppare
una molte di lavoro impressionante.

<<“Con molti occhi puntati addosso, ogni bug diventa una bazzecola>>

... a patto che siano occhi attenti, in grado di capire e dotati di
una strumentazione diagnostica adeguata :-)

OTH
Sandro

_______________________________________________
Gfoss a lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni
dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20150918/04bffa4c/attachment.html>