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

Ven 18 Set 2015 20:50:13 CEST

Ciao Giuseppe,

Il giorno 18 settembre 2015 18:07, Giuseppe Sucameli <brush.tyler a gmail.com>
ha scritto:

> Ciao Roberto,
> se il problema che segnali è così fastidioso puoi:
>
> Ipotesi 1) Correggerlo da te,
> Ipotesi 2) Pagare qualcuno che lo faccia al posto tuo.
>

Provvederò al più presto ad andare a fondo alla cosa,  dato che ho
esperienza di 30 anni da programmatore.
Non ho bisogno di pagare nessun (altro) programmatore.  E sono sicuro che
sarò in buona compagnia (vero, Alessandro ?).

Per quanto riguarda il problema, se ritieni che un crash improvviso durante
una qualunque funzione sia un fatto insignificante,
sappi che stiamo (noi entusiasti di QGIS e dell'Open Source) perdendo
credibilità, purtroppo, presso i grandi enti presso i quali,
con grande fatica e pazienza, siamo riusciti a introdurlo (e Paolo sa bene
di quali enti sto parlando).

> C'è qualche altra ipotesi?
>
> A dire il vero ce n'è un'altra:
> Ipotesi 3) Smettere di usare QGIS.
>

Questa ipotesi non riguarda me, che ho investito su QGIS, come tempo,
risorse e plugin.
Purtroppo per tutti noi può iniziare a riguardare gli enti pubblici a cui
ci stiamo rivolgendo.

>
> Sinceramente, le tue parole sono inaccettabili. (troll?)
>
> Non ho mai dato un'occhiata ad un minidump, oltre tutto se anche volessi
> dovrei tirare su una VM, installare Windows, installare e configurare
> l'ambiente
> di compilazione...
> Mi ci vorrebbe almeno una settimana solo per essere operativo.
>
> Tuttavia, mi chiedo perché mai dovrei sprecare le mie serate per te che
> pensi che tutto sia dovuto.
>

A me non è dovuto nulla.

E' solo dovuto rispetto per gli utenti (pubblici e non) che perdono ore di
tempo e modifiche dei dati su cui stanno lavorando
(è vero, Luca ?).

Il tempo è prezioso per tutti.  Anche il mio.

Questo è il link alla segnalazione del bug, che forse potresti andare a
consultare :

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

Cordiali saluti

Roberto

> Cordialmente.
> Giuseppe
>
>
> 2015-09-18 11:20 GMT+02:00 Geo DrinX <geodrinx a gmail.com>:
>
>> 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
>>
>>
>> _______________________________________________
>> 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
>>
>
>
>
> --
> Giuseppe Sucameli
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20150918/f6d64fa4/attachment-0001.html>