Re: Segfaults
On 12/10/21 07:06, Diego Zuccato wrote:
Il 11/10/2021 20:15, Davide Prina ha scritto:
Tieni presente che se installi qualcosa da sistemi terzi gli script di
installazione potrebbero modificare file/link di sistema...
Si, lo fanno. Configurazione di PAM e di sshd, ma non alle lib.
quando installi un pacchetto .deb viene eseguito come root e come root
può fare di tutto...
Nessuno dei due è linkato con libopenblas0 o libopenblas0-pthread, ma
il pacchetto cdo dipende da entrambe.
questo non vuol dire. Può essere che chiami altro binario
(eseguibile/libreria) che dipende da queste librerie
O che faccia come octave ed usi dlopen.
ldd lista solo le lib necessarie, non quelle opzionali o i "plugin".
no, ldd indica tutte le librerie linkate dinamicamente
Una libreria linkata dinamicamente può non essere presente...
l'importante è che l'eseguibile non la chiami e se è opzionale ci sarà
un controllo che non la fa chiamare.
$ apt show octave
[...]
Recommends: gnuplot-qt | gnuplot-x11 | gnuplot-nox, libopenblas0 |
libatlas3-base, pstoedit, epstool, default-jre-headless, octave-doc
[...]
ma hai installato anche libatlas3-base? hai provato ad installare
questo quando non è installato cdo e libopenblas0 per vedere se ti va
in segfault?
Magari se installi questo poi non ti installa libopenblas0
Purtroppo no:
# apt install libatlas3-base
Lettura elenco dei pacchetti... Fatto
Generazione albero delle dipendenze... Fatto
Lettura informazioni sullo stato... Fatto
libatlas3-base è già alla versione più recente (3.10.3-10).
0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.
cioè anche se hai installato libatlas3-base ti installa allo stesso
anche libopenblas0?
Se sì, allora probabilmente c'è qualcosa che dipende da questo.
Allora come controprova puoi provare ad installare libopenblas0 e
rimuovere libatlas3-base prima di fare l'installazione dei pacchetti che
non terminano... ma leggendo più avanti il problema è proprio
libopenblas0 e quindi questa controprova è inutile.
prova con valgrind, individui qualcosa di "piccolo" che va in crash
subito ed esegui:
$ valgrind --leak-check=full --num-callers=50 --show-reachable=no \
--show-possibly-lost=no --track-origins=yes --trace-children=yes \
--read-var-info=yes $ESEGUIBILE > risultato.txt
Direi che conferma in pieno la diagnosi:
$ valgrind --leak-check=full --num-callers=50 --show-reachable=no
--show-possibly-lost=no --track-origins=yes --trace-children=yes
--read-var-info=yes octave > octave.out
==746909== Command:
/usr/libexec/octave/6.2.0/exec/x86_64-pc-linux-gnu/octave-gui
==746909==
==746909== Thread 9:
==746909== Jump to the invalid address stated on the next line
==746909== at 0x0: ???
==746909== by 0xBDFD708: blas_memory_alloc (memory.c:2793)
==746909== by 0xBDFDF03: blas_thread_server (blas_server.c:366)
==746909== by 0x8D33EA6: start_thread (pthread_create.c:477)
==746909== by 0x725EDEE: clone (clone.S:95)
==746909== Address 0x0 is not stack'd, malloc'd or (recently) free'd
questo errore non l'ho mai incontrato prima.
Apri un bug su libopenblas0, segnala come riprodurlo, installando
octave, ... e riportando questo come risultato dell'esecuzione di octave
Cioè in blas_memory_alloc() va a richiamare un NULL pointer.
Probabilmente una callback non è stata correttamente inizializzata.
Secondo me è stato inizializzato a 0 e poi non inserito un valore di
puntamento adeguato/corretto
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);
si potrebbe ricompilare la libreria impostando a 1 DEBUG
per esempio alla riga 72 mettere
#define DEBUG 1
così da avere un po' di log di debug e capire meglio cosa succede
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
il pacchetto lo trovi qui:
https://packages.debian.org/bookworm/libopenblas0
se poi non va ti conviene rimettere il pacchetto di stable.
In realtà prima serve sapere in che sorgente c'è il problema e quindi
bisogna installare i simboli di debug:
[...]
A questo punto rieseguendo l'istruzione con valgrind ti riporta il
nome del sorgente e la riga di quel sorgente.
Fatto. memory.c:2793 . Ma su github corrisponde a una #endif ...
devi guardare la versione che stai usando tu e non quella in sviluppo,
vedi qui:
https://sources.debian.org/src/openblas/0.3.13+ds-3/driver/others/memory.c/
Altra strada che seguirei è:
1) verificare se i pacchetti installati non hanno problemi (mancanza
di file o "errori" nei file installati)
# debsums -as
2) verificare se ci sono file in più o mancano file nel tuo sistema...
il risultato del comando è quasi di sicuro enorme ed è da analizzare
accuratamente... dovresti escludere tutte le directory che contengono
dati/file non di sistema
$ apt show cruft
ROFLASTC :) Solo per la scansione di /home e /scratch mi ci mette due
giorni :) Ho dovuto anche rimuovere locate :(
per il punto 1 ci mette un tempo accettabile.
Il punto 2 devi escludere tutte le directory dove ci sono file non di
sistema, altrimenti non finisce davvero più e ti crea un file gigantesco
perché, per ogni file che trova di questi, ti dice che non sa come sia
stato creato...
Ciao
Davide
--
Motivi per non comprare/usare ms-windows-vista:
http://badvista.fsf.org/
Non autorizzo la memorizzazione del mio indirizzo su outlook
Reply to: