minidump alla chiusura di Qgis...
Locked
123
123
 
|
A lezione insegno che qgis crusha su win improvvisamente almeno ogni 30 minuti ..... corrompendo il file di progetto, quindi fare sempre copia e incolla. ... riuscissi ad aprire un file dump !!! Il 04/set/2015 15:05, "Geo DrinX" <[hidden email]> ha scritto:
_______________________________________________ [hidden email] 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 |
Re: minidump alla chiusura di Qgis...
|
|
Il giorno 4 settembre 2015 15:57, Luca Mandolesi <[hidden email]> ha scritto: A lezione insegno che qgis crusha su win improvvisamente almeno ogni 30 minuti ..... corrompendo il file di progetto, quindi fare sempre copia e incolla. ... riuscissi ad aprire un file dump !!! Davvero è così terrificante la situazione con le ultime release? Negli ultimi due anni l'ho usato molto poco ma non ricordo una situazione devastante come quella che descrivi. Se è così credo che debba essere corretto immediatamente o il futuro di QGIS rimarrà ristretto ad una piccola cerchia di appassionati :( Stefano --------------------------------------------------- 41.95581N 12.52854E http://www.linkedin.com/in/stefanoiacovella http://twitter.com/#!/Iacovellas _______________________________________________ [hidden email] 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 |
|
Io ci lavoro tutti i giorni con Qgis dalla versione 2.2 a quella odierna 2.10. Sotto Windows (da xp a windows 8) ho subito pochissimi minidump e senza danni al file di progetto. Il 04/set/2015 16:18 "Stefano Iacovella" <[hidden email]> ha scritto:
_______________________________________________ [hidden email] 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 |
|
|
Ho dei minidump con cadenze di 30 minuti...il problema è che su due macchine..due comportamenti diversi....e senza poter leggere un minidump non so cosa lo provochi. A volte i.copia incolla, altre volte cliccare sui pulsanti degli stili, altre chiudendo qgis...tutti fenomeni che non riesco a replicare in base alla mia percezione del problema. Il 04/set/2015 17:10, "Totò Fiandaca" <[hidden email]> ha scritto:
_______________________________________________ [hidden email] 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 |
Re: minidump alla chiusura di Qgis...
|
|
In reply to this post by geodrinx
Sicuramente l'uscita da un ambiente multitasking e' un evento che se
non gestito propriamente puo' risultare traumatico per un software. Detto questo, occorrerebbe riuscire a identificare il caso specificoche provoca il crash. Io , ad esmepio, non ho esperienza di questi crash in uscita. Pero' e' anche vero che ne faccio un uso non intensivo come quello che puo' avvenire durante un corso di gis. Provando a analizzare il problema: Partendo dal presupposto che non sono stati inseriti (inavvertitamente) dei bugs di codice. Il crash e' probabilmente dovuto a una qualche condizione non gestita al momento del'uscita dal programma. Prima QGIS non era multitask. Di conseguenza prima di uscire doveva giocoforza terminare ogni elaborazione che aveva in corso. Questo dava sicuramente la garanzia al programmatore che al momento in cui usciva non vi fossero risorse impegnate. Files non chiusi magari anchein scrittura. E anche un eventuale salvataggio del progetto qgis era sicuramente terminato. Ora tutto questo non e' piu' vero. Occorre quindi gestire le segnalazioni tra i vari compoenenti del programma. Una domanda: per caso avete qualche settaggio deltipo: salva ogni 10 minuti oppure "salva prima di chiudere" attivo ? Qualcosa che possa giustificare l'avvio di una scrittura sul file di progetto durante la sua chiusura ? A. Il 4 settembre 2015 15:05, Geo DrinX <[hidden email]> ha scritto: > Sandro, > > >> >> Non creare dump non nasconde il problema, semplicemente non lascia >> in giro un file potenzialmente utile per il debugging ma inutile per >> l'utente, che comunque viene informato del crash. > > > > Se fossi credente, direi: "Parole Sante !" > > >> >> > Domanda: su Unix, o Linux, QGIS non crasha mai ? Buffo: su MacOSX >> > crasha. >> >> Crasha spesso e volentieri. Devo dire nelle ultimi tempi molto meno >> di prima. Io uso felicemente la versione stabile 2.8 e non ho >> esperienze di crash (qualcuna di deadlock, riportata, ma non >> crash...). > > > > Ah, ecco. Quindi, non si tratta di un "solito problema windows". > > > >> >> Ho il forte sospetto che l'introduzione del multithreading abbia >> reso piu' instabile l'applicazione (il crash on exit e' tipico). >> >> --strk; > > > > Beh, diciamo che io ne sono sicuro. Ma forse mi sarei aspettato qualche > conferma autorevole (che spero stia lavorando su questo). Ho anche > un'altra ipotesi: ci sono dei rami secchi, all'interno di QGIS, che > potrebbero fare danni. Ad esempio, un certo "Globo" abbandonato lì > dentro, non usabile, ma compilato con le sue belle librerie wxWidgets e > OpenSceneGraph, in versioni incompatibili tra di loro (?) e forse anche > incompatibili con le altre librerie attuali GDAL eccetera. > > Qualcuno è in grado di escludere questo ? Forse è il caso di segnalarlo > anche sul tracker e in lista qgis-developer (a proposito, che fine ha > fatto la mia eMail riguardante questo lì dentro ? Sono in attesa... ) > > Rimango fiducioso. > > A presto > > Roberto > > > > >> >> >> () Free GIS & Flash consultant/developer >> /\ http://strk.keybit.net/services.html > > > > _______________________________________________ > [hidden email] > 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 -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] 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 |
|
|
In reply to this post by mando
Il 04/09/2015 17:24, Luca Mandolesi ha scritto:
> Ho dei minidump con cadenze di 30 minuti...il problema è che su due > macchine..due comportamenti diversi....e senza poter leggere un minidump > non so cosa lo provochi. A volte i.copia incolla, altre volte cliccare > sui pulsanti degli stili, altre chiudendo qgis...tutti fenomeni che non > riesco a replicare in base alla mia percezione del problema. molto strano. hai provato ad escludere i plugins? scommetto una birretta che il problema, almeno in caso di crash cosi' frequenti, e' li'. saluti. -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS courses: http://www.faunalia.eu/training.html _______________________________________________ [hidden email] 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 |
|
|
Paolo, il fatto è che io non ho installato plugin aggiuntivi.... 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. Altra domandona: una situazione di crush avviene mentre si digitalizzano molti oggetti con molti vertici (parlo di archeologia pietruzza per pietruzza) non si salva il lavoro di digitalizzazione e c'è nelle impostazioni generali la verifica delle geometrie attiva... è possibile che dovendo costantemente controllare centinaia di migliaia di vertici mentre si digitalizza (parlo di un layer che ha almeno 80.000 geometrie e ognuna ha come minimo 10-15 vertici....come funziona la verifica delle geometrie? Controlla tutto di continuo? _______________________________________________ [hidden email] 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 |
|
|
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 _______________________________________________ [hidden email] 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 |
|
Questo tuo intervento è bellissimo ! Una vera e propria autorevole "lezione" di informatica.
Inoltre definisce un punto chiaro su come approcciarsi correttamente di fronte a questi "dump" senza perdersi in chiacchiere. Per cui ti ringrazio e ... se permetti, me la conservo !! Un'unica mia perplessità è quando dici : ... forse sopravvaluti la platea, ma non so, tra gli utenti di QGIS, quanti siano questi "molti" di cui parli !?  Cari saluti Nino |
|
|
On Sat, 5 Sep 2015 04:09:39 -0700 (MST), nformica wrote:
> Un'unica mia perplessità è quando dici : > > a.furieri wrote >> invece fortunatamente molti utenti sono in grado di compilarsi >> autonomamente l'applicazione a partire dai sorgenti. > > ... forse sopravvaluti la platea, ma non so, tra gli utenti di QGIS, > quanti > siano questi "molti" di cui parli !? > Nino, ovviamente non ho numeri oggettivi, piu' che altro sensazioni ed esili segnali di fumo. almeno in base a quel che leggo sulle varie ML internazionali i topics relativi a qualche problema in fase di ./configure e/o di compilazione figurano sempre regolarmente tra gli argomenti piu' popolari e ricorrenti, segno che dopo tutto non sono affatto pochi gli utenti che si fanno "in casa" le proprie build. probabilmente QGIS e' un package cosi' grosso ed impegnativo che finisce per scoraggiare le build custom, ma sicuramente in giro per il mondo ci sono svariate centinaia di utenti che si avventurano piu' o meno regolarmente su questa strada. anche tra gli italiani quelli che ci hanno provato almeno una volta verosimilmente dovrebbero essere almeno alcune decine ... non bastano certo per fare una folla oceanica, ma sono sicuramente molto piu' numerosi degli sviluppatori attivi ;-) ciao Sandro _______________________________________________ [hidden email] 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 |
Re: scienza e stregoneria (was minidump alla chiusura di Qgis...)
|
|
Io ho provato varie volte con VC++, a compilare il tutto, ma non ci
sono mai riuscito. Piu' che il codice di QGIS e' il codice delle librerie esterne da cui dipende che e' rognoso su windows. QGIS e' 90% altre librerie e 10% codice suo. Poi ci ho rinunciato. A. Il 5 settembre 2015 13:53, <[hidden email]> ha scritto: > On Sat, 5 Sep 2015 04:09:39 -0700 (MST), nformica wrote: >> >> Un'unica mia perplessità è quando dici : >> >> a.furieri wrote >>> >>> invece fortunatamente molti utenti sono in grado di compilarsi >>> autonomamente l'applicazione a partire dai sorgenti. >> >> >> ... forse sopravvaluti la platea, ma non so, tra gli utenti di QGIS, >> quanti >> siano questi "molti" di cui parli !? >> > > Nino, > > ovviamente non ho numeri oggettivi, piu' che altro sensazioni > ed esili segnali di fumo. > > almeno in base a quel che leggo sulle varie ML internazionali i > topics relativi a qualche problema in fase di ./configure e/o di > compilazione figurano sempre regolarmente tra gli argomenti piu' > popolari e ricorrenti, segno che dopo tutto non sono affatto pochi > gli utenti che si fanno "in casa" le proprie build. > > probabilmente QGIS e' un package cosi' grosso ed impegnativo che > finisce per scoraggiare le build custom, ma sicuramente in giro > per il mondo ci sono svariate centinaia di utenti che si avventurano > piu' o meno regolarmente su questa strada. > anche tra gli italiani quelli che ci hanno provato almeno una volta > verosimilmente dovrebbero essere almeno alcune decine ... non bastano > certo per fare una folla oceanica, ma sono sicuramente molto piu' > numerosi degli sviluppatori attivi ;-) > > ciao Sandro > > _______________________________________________ > [hidden email] > 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 -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] 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 |
|
|
E cmq...noi installiamo solo da Osgeo Advanced installer e l'errore appare sempre col medesimo messaggio, ma non necessariamente con la stessa sequenza di operazioni, ergo, non replicabile per un utente basic come me...ergo, io che sono un potenziale finanziatore, vengo scoraggiato a farlo. La lezione di informatica è eccezionale...ma mi sa Alessandro che la devi fare in inglese su QGis dev, almeno vediamo che rispondono e che sia valida anche per lo standalone.... io a conoscenze informatiche pari a zero dico che dipende molto dalle configurazioni di windows, dato che su ppiù macchine vedo comportamenti diversi. _______________________________________________ [hidden email] 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 |
Re: scienza e stregoneria (was minidump alla chiusura di Qgis...)
|
|
In reply to this post by a.furieri
On Sat, Sep 05, 2015 at 11:54:08AM +0200, [hidden email] wrote:
> > QUEL SOFTWARE CONTIENE VARIABILI NON INIZIALIZZATE > Altrettanto facilmente: memory overflow che per pura sventura avviene non al di fuori dello spazio di indirizzamento ammesso per il programma, ma nella sua area dati. Il programma continua a girare (niente stack overflow, errore di segmentazione, errore di paginazione ecc.) ma presenta comportamenti o risultati anomali, che per di più cambiano in base allo stato della memoria. Atrimenti detto "HeisenBug" (ma non ci sta proprio niente da ridere quando capita). Spessissimo se si usa il programma dentro un debug, non si riesce a riprodurre, se si cambia l'input idem, se si cambia pc anche ecc. Happy hacking -- Francesco P. Lovergine _______________________________________________ [hidden email] 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 |
|
|
> [hidden email] wrote: >> >> QUEL SOFTWARE CONTIENE VARIABILI NON INIZIALIZZATE > > Altrettanto facilmente: memory overflow che per pura sventura avviene non al di fuori > dello spazio di indirizzamento ammesso per il programma, ma nella sua area dati. > Il programma continua a girare (niente stack overflow, errore di > segmentazione, errore di paginazione ecc.) ma presenta comportamenti o > risultati anomali, che per di più cambiano in base allo stato della memoria. > Atrimenti detto "HeisenBug" (ma non ci sta proprio niente da ridere quando > capita). Spessissimo se si usa il programma dentro un debug, non si riesce > a riprodurre, se si cambia l'input idem, se si cambia pc anche ecc. > > Happy hacking > Francesco P. Lovergine Grazie, Francesco. A proposito di Hacking, questo mi sembra un buon argomento da proporre nella prossima HackFest 2015 di QGIS. Comunque, sembra che non si tratti di semplice responsabilità di qualche plugin python, anche perchè, nei test che ho effettuato, i plugin sono stati completamente disattivati. Alle Canarie la birra scorrerà a fiumi. :) A presto Roberto ( GeoDrinX ) _______________________________________________ [hidden email] 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 |
|
|
In reply to this post by a.furieri
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 ---------- Messaggio inoltrato ---------- Da: <[hidden email]> Date: 5 settembre 2015 11:54 Oggetto: [Gfoss] scienza e stregoneria (was minidump alla chiusura di Qgis...) A: [hidden email] On Sat, 5 Sep 2015 09:34:21 +0200, Luca Mandolesi wrote: Si parla di una macchina con windows 8 e un database in 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 _______________________________________________ [hidden email] 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 _______________________________________________ [hidden email] 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 |
|
|
Il 18/09/2015 11:20, Geo DrinX ha scritto:
> 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 ? chi sarebbe lo struzzo? -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS courses: http://www.faunalia.eu/training.html _______________________________________________ [hidden email] 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 |
Re: Fwd: scienza e stregoneria (was minidump alla chiusura di Qgis...)
|
|
In reply to this post by geodrinx
l giorno 18 settembre 2015 11:20, Geo DrinX <[hidden email]> ha scritto:
Mai visto un minidump... quindi per me il problema non esiste, comunque rispondo. Ipotesi 3: lo struzzo ha di meglio da fare. Però non sono sicuro di aver capito chi è lo struzzo: il PSC o gli sviluppatori QGIS in generale? Francamente non capisco l'atteggiamento: chi contribuisce a QGIS (o a qualsiasi altro sw libero) normalmente lo fa in maniera volontaria, se e quando ha tempo e voglia. Se lo paghi è un altro discorso: hai fatto un contratto con uno struzzo perchè ti risolva questo particolare problema? Se è così importante per te, perchè non fai una colletta (adesso si chiama crowdfunding) e assoldi uno struzzo perchè cerchi di risolverlo? PS: Grazie per lo struzzo, in fondo ci sono animali meno simpatici. _______________________________________________ [hidden email] 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 |
|
|
beh, in effetti il problema del minidump è molto serio in quanto:
ciao Il giorno 18 settembre 2015 11:59, Alessandro Pasotti <[hidden email]> ha scritto:
_______________________________________________ [hidden email] 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 |
|
|
Il 18/09/2015 12:04, Totò Fiandaca ha scritto:
> 5. sembra veramente un bug creato ad arte!!!! ma non si capisce il > perchè!!! per piacere, smettete di seminare queste illazioni fumose. sono davvero disturbanti, specie per quei pochi che si impegnano ogni giorno per fornirvi liberamente un prodotto su con cui molti di voi lavorano ogni giorno, spessissimo senza restituire niente. Grazie. -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS courses: http://www.faunalia.eu/training.html _______________________________________________ [hidden email] 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 |
Re: Fwd: scienza e stregoneria (was minidump alla chiusura di Qgis...)
|
|
In reply to this post by geodrinx
Ciao Roberto, se il problema che segnali è così fastidioso puoi: A dire il vero ce n'è un'altra: Ipotesi 3) Smettere di usare QGIS. 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. Cordialmente. Giuseppe2015-09-18 11:20 GMT+02:00 Geo DrinX <[hidden email]>:
-- Giuseppe Sucameli
_______________________________________________ [hidden email] 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 |
«
Return to Gfoss -- Geographic Free and Open Source Software - Italian mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |