Il 13/10/2021 21:41, Davide Prina ha scritto:
se devo essere onesto mi sono un po' perso, anche perché non sapendo
come sono impostate quelle variabili non si può sapere cosa memoryalloc
contenga come elemento 0 e successivi
Non in modo preciso perché dipende da vari #ifdef, ma viene
inizializzato nella stessa funzione, un centinaio di righe più sopra.
se non erro li viene eseguita la funzione che è stata inserita in
memoryalloc nella posizione 0 passando come parametro base_address con
cast void*
Esatto.
e memoryalloc è un vettore di puntatori a funzione che prendono come
parametro void*... però tale lista dipende, penso, dal tuo sistema e da
come sono configurate determinate variabili
Solo da come è stata compilata la lib, direi.
visto che l'errore è jump to invalid address at 0x0 sembra che il
puntatore a funzione memoryalloc[i] punti all'indirizzo 0x0 che non
dovrebbe prima di tutto essere raggiungibile da un programma e quindi
non dovrebbe contenere una funzione da eseguire.
L'ultimo elemento, che marca la fine dell'array, è sempre NULL.
Probabilmente la condizione per il while alla 2791 dovrebbe essere
relativa a *func, non a func...
quindi tu dici il memoryalloc[i] == NULL
func -> memoryalloc[i] != NULL, poiché il suo indirizzo è quello
relativo all'i-esimo elemento di memoryalloc, ma tale i-esimo elemento
contiene NULL e quindi quando esegue la funzione cerca di andare
all'indirizzo 0x0 per eseguirla
Esatto.
è vero l'istruzione dovrebbe essere
while ((*func != NULL) && (map_address == (void *) -1))
poiché func è sempre un elemento di memoryalloc.
E memoryalloc, essendo locale e allocata sullo stack, non può essere NULL.
Però questo vuol dire che non ha trovato nessun metodo per eseguire
l'allocazione di memoria... quindi potrebbe avere problemi dopo, anche
perché c'è un ciclo più esterno e quindi rieseguirebbe quello più
interno... potrebbe essere addirittura che memoryalloc[0] == NULL perché
nessuno degli altri è stato impostato.
Può essere che vada in out of memory. E' una cosa da considerare, quando
si usa malloc :)
quindi risolvi installando libopenblas0-serial e togliendo
libopenblas0-pthread?
Esatto.
interessante:
$ apt show libopenblas0-serial
[...]
Configurazione: USE_THREAD=0 USE_OPENMP=0 INTERFACE64=0
[...]
quindi magari bastava eseguire:
$ USE_THREAD=0 octave
No, non sono variabili d'ambiente ma #define gestite a compile time.
o anche aggiungendo gli altri per avere octave funzionante senza segfault
Una volta che il bin è compilato, c'è il segfault.
visto che prima funzionava puoi cercare la versione della libreria che
non causava questi problemi e capire così cosa è cambiato confrontando
il sorgente che ti ha indicato valgrind
E intanto gli utenti mi saltano alla gola :)
quindi probabilmente non la usavi o è cambiato qualcos'altro che ha
fatto venire a galla questo bug
Io non la usavo, gli utenti si. Comunque ho girato tutto ai maintainer,
che conoscono il codice molto meglio di me (io so a malapena cosa
dovrebbe fare ad alto livello, e ho trovato quello che da vecchio
programmatore C mi pare un errore tipico) e che spero sapranno
considerare tutti gli elementi.
ma non puoi clonarlo in una macchina virtuale e fare da li le prove?
Il problema è sempre il tempo, purtroppo. Al momento, per questo c'è un
workaround e il prossimo problema (magari fosse solo uno... dopo
l'aggiornamento *alcuni* job con IntelMPI non partono più, devo cambiare
il sistema d'autenticazione per eliminare pbis, ecc) deve venire risolto.
Comunque grazie delle dritte, sono state molto utili!
--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786
