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

Ven 18 Set 2015 22:02:04 CEST

Bene, allora mi pare siamo allineati.

[flame=on]
Però mi sfugge, a fronte delle forti motivazioni che manifesti (30 anni di
programmazione, uno che ha investito molto nell'opensource, ...), cosa ti
ha portato a scrivere quell'email.

Come può uno che come te dice di capirne:
* pensare che qualcuno abbia intenzionalmente inserito un bug nel codice
(in effetti suona proprio come un vero approccio opensource, in barba al
codice libero!),
* oltretutto sarebbe poco furbo, dato che se così fosse e lo str**zo (cit.)
ragionasse in termini di denaro, come tu ipotizzavi, perderebbe clienti.
Non è nemmeno detto che i soldi andrebbero a lui,
* se poi aggiungiamo le offese gratuite... da uno che, data la lunghissima
esperienza, dovrebbe ben sapere che i bug non sempre sono facili da
schiacciare (o forse tu scrivi solo codice senza bug?)
[/flame=off]

A parte il flame gratuito (scusate), torniamo a dare valore alla
discussione.

Ho passato 3 sere/notti (mio tempo libero dunque, visto che io QGIS non lo
uso né per lavoro né per diletto) alla ricerca del fantastico bug (e forse
adesso capirai perché questo tuo atteggiamento mi ha fatto particolarmente
scaldare...).
Comunque, ahimé non sono riuscito a capire perché avviene questo random
crash in chiusura sotto Ubuntu14.04. Sembra avvenire durante alla cleanup
delle risorse allocate in python, ma sotto Windows potrebbe avvenire da
un'altra parte, chi lo sa.

Fammi sapere se riesci/riuscite a risolvere il problema, sono curioso.

Ciao.
Giuseppe

Sent from mobile. Sorry for being short.
--
Giuseppe Sucameli
Il 18/set/2015 20:50, "Geo DrinX" <geodrinx at gmail.com> ha scritto:

> Ciao Giuseppe,
>
> Il giorno 18 settembre 2015 18:07, Giuseppe Sucameli <
> brush.tyler at 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 at 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 at lqt.it>
>>> Date: 5 settembre 2015 11:54
>>> Oggetto: [Gfoss] scienza e stregoneria (was minidump alla chiusura di
>>> Qgis...)
>>> A: gfoss at 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 at 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 at 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20150918/0d2f9dd3/attachment-0001.html>