On 13/10/21 07:27, Diego Zuccato wrote:
Il 12/10/2021 19:43, Davide Prina ha scritto:
vedendo qui:
https://sources.debian.org/src/openblas/0.3.13+ds-3/driver/others/memory.c/
l'istruzione è questa:
map_address = (*func)((void *)base_address);
Uhm... Il codice usa l'array memoryalloc come lista di puntatori a
funzione. Però poi itera gli elementi senza verificare se uno di essi è
NULL. E l'ultimo lo è sempre (riga 2664).
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
se non erro li viene eseguita la funzione che è stata inserita in
memoryalloc nella posizione 0 passando come parametro base_address con
cast void*
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
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.
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
è vero l'istruzione dovrebbe essere
while ((*func != NULL) && (map_address == (void *) -1))
poiché func è sempre un elemento di memoryalloc.
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.
Certo che comunque qualcosa non mi torna: se metto la -serial invece
della -pthread, senza cambiare altro, octave funziona...
quindi risolvi installando libopenblas0-serial e togliendo
libopenblas0-pthread?
interessante:
$ apt show libopenblas0-serial
[...]
Configurazione: USE_THREAD=0 USE_OPENMP=0 INTERFACE64=0
[...]
quindi magari bastava eseguire:
$ USE_THREAD=0 octave
o anche aggiungendo gli altri per avere octave funzionante senza segfault
Altro modo è provare a prendere da testing la versione nuova e vedere
se questo risolve, vedendo le dipendenze dovrebbe essere possibile
installare solo il pacchetto preso da testing
Purtroppo non risolve :(
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
le versioni precedenti della libreria li trovi qui:
https://snapshot.debian.org/binary/libopenblas0-pthread/
o guardare nei sorgenti precedenti.
Però anche in Buster c'era lo stesso while
https://sources.debian.org/src/openblas/0.3.5+ds-3/driver/others/memory.c/
ma anche in Stretch
https://sources.debian.org/src/openblas/0.2.19-3/driver/others/memory.c/
quindi probabilmente non la usavi o è cambiato qualcos'altro che ha
fatto venire a galla questo bug
Magari mi limito a segnalare la cosa al maintainer. Purtroppo è un
sistema di produzione e non posso fare troppi test :(
ma non puoi clonarlo in una macchina virtuale e fare da li le prove?
Ciao
Davide
--
Esci dall'illegalità: utilizza LibreOffice/OpenOffice:
http://linguistico.sf.net/wiki/doku.php?id=usaooo
Non autorizzo la memorizzazione del mio indirizzo su outlook
