minidump alla chiusura di Qgis...

[stefano campus]

brrrrr...
ma che cose brutte mi fate leggere!

"Dietrologia è un termine coniato in Italia nel 1974, nel linguaggio politico e giornalistico, e indica la ricerca di supposte motivazioni nascoste che sarebbero all'origine di un avvenimento." [wikipedia]

s.

[geodrinx]

Ciao Giuseppe,

Il giorno 18 settembre 2015 18:07, Giuseppe Sucameli <[hidden email]> 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 <[hidden email]>:

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: <[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
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

_______________________________________________
[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

--

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

[Giuseppe Sucameli]

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" <[hidden email]> ha scritto:

Ciao Giuseppe,

Il giorno 18 settembre 2015 18:07, Giuseppe Sucameli <[hidden email]> 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 <[hidden email]>:

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: <[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
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

_______________________________________________
[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

--

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

[mando]

Ieri ci si è presentata una sequenza di minidump ogni 10 minuti circa, utilizzando un unico layer con un categorizzato secondo regole...abbiamo riavviato il PC ma la cosa ha continuato.

Oggi riaperto il medesimo progetto con un solo layer sparito...minidump sparito...il fatto è che a quanto pare non si capisce proprio da dove parta  e mi chiedo quanto possa pagare un programmatore per qualcosa che appare e scompare agli occhi dei mortali in tempi e modi diversi di giorno in giorno.

Minidump is Magic! 

Ci facciamo le magliette???

:)

Luca

_______________________________________________
[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