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.furi...@lqt.it> Date: 5 settembre 2015 11:54 Oggetto: [Gfoss] scienza e stregoneria (was minidump alla chiusura di Qgis...) A: gfoss@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@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
_______________________________________________ Gfoss@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
