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


Rispondere a