Re: Segfaults
Il 11/10/2021 20:15, Davide Prina ha scritto:
è meglio che rispondi sempre in lista, potresti trovare aiuto da altri,
se invece scrivi solo a una persona può essere che perdi l'aiuto che ti
permette di risolvere.
A volte mi salta lo shift :( Hai ragione.
- disinstallato pbis-open cdo octave
ma questo non è detto che rimuova tutto ciò che è stato installato da
quel repository
- effettuato un autoremove
neanche questo ti assicura la rimozione di tutto ciò che è stato
installato da quel repository
No, ma ho verificato con apt-show-versions :)
Spero che questo lo mostri...
ma quando rimuovevi sopra pbis-open, poi rimuoveva anche pbis-open-upgrade?
Lo rimuove con l'autoremove in quanto non più utilizzato.
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.
però non capisco, se installi solo Octave funziona e sembra non usare
tale libreria, se installi anche cdo si ha che Octave va in crash...
probabilmente cdo, o le librerie che carica, modificano qualche
configurazione di sistema
No, semplicemente octave usa dlopen per caricare opzionalmente libblas0.
File octave/liboctave/util/blaswrap.c :
apple_vecLib = dlopen (VECLIB_FILE, RTLD_LOCAL | RTLD_NOLOAD | RTLD_FIRST);
Essendo opzionale, non può dichiararla tra le dipendenze.
no, da root non devi mai eseguire dei programmi utente, mai.
:)
$ ldd /usr/bin/octave
ldd /usr/bin/octave
linux-vdso.so.1 (0x00007ffef04ec000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6
(0x00007fc3e75fa000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x00007fc3e742d000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x00007fc3e7413000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007fc3e73f1000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
(0x00007fc3e722c000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1
(0x00007fc3e7201000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
(0x00007fc3e71f9000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
(0x00007fc3e70b5000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc3e776c000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6
(0x00007fc3e70b0000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6
(0x00007fc3e6eaa000)
libbsd.so.0 => /usr/lib/x86_64-linux-gnu/libbsd.so.0
(0x00007fc3e6e93000)
libmd.so.0 => /usr/lib/x86_64-linux-gnu/libmd.so.0
(0x00007fc3e6e84000)
Sembra che octave sia "furbo" e che carichi dinamicamente altre lib :(
no, al massimo vedevi qui che necessitava di una libreria, ma non la
trovata (alcuni mettono negli script di avio i path per trovare le
librerie).
In questo caso può essere che una di queste o altro componente chiamato
da Octave quando è in esecuzione chiami quelle librerie.
Come confermato dal sorgente, octave usa direttamente dlopen .
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".
$ apt rdepends libopenblas0
[...]
Dipende: python3-qiskit-aer
|Raccomanda: octave
[...]
$ 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.
E questo mi fa pensare *molto* seriamente ad un bug in libopenblas che
non controlla un'allocazione...
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
dove al posto di $ESEGUIBILE metti il nome, esempio octave e lo fai
seguire degli eventuali parametri, poi esegui i passi che portano al
segfault
Nel file risultato.txt dovresti avere l'indicazione di errati usi di
memoria. Il file potrebbe essere molto lungo.
Interessanti sono:
* doppi free o delete
* uso di puntatore non allocato
* uso di puntatore non inizializzato
se trovi qualcosa di tutto questo è possibile capire al volo dove si
trovi il problema.
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== Memcheck, a memory error detector
==746909== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==746909== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright
info
==746909== Command: octave
==746909==
==746909== Memcheck, a memory error detector
==746909== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==746909== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright
info
==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
==746909==
==746909==
==746909== Process terminating with default action of signal 11
(SIGSEGV): dumping core
==746909== Bad permissions for mapped region at address 0x0
==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==
==746909== HEAP SUMMARY:
==746909== in use at exit: 145,672 bytes in 928 blocks
==746909== total heap usage: 1,534 allocs, 606 frees, 301,786 bytes
allocated
==746909==
==746909== LEAK SUMMARY:
==746909== definitely lost: 0 bytes in 0 blocks
==746909== indirectly lost: 0 bytes in 0 blocks
==746909== possibly lost: 5,088 bytes in 13 blocks
==746909== still reachable: 140,584 bytes in 915 blocks
==746909== suppressed: 0 bytes in 0 blocks
==746909== Reachable blocks (those to which a pointer was found) are not
shown.
==746909== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==746909==
==746909== For lists of detected and suppressed errors, rerun with: -s
==746909== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 0 from 0)
Errore di segmentazione
Cioè in blas_memory_alloc() va a richiamare un NULL pointer.
Probabilmente una callback non è stata correttamente inizializzata.
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 ...
Poi se vuoi indagare su sorgenti di grosse dimensioni, senza sapere
nulla di cosa fanno c'è l'eccezionale cscope... ti permette in un batter
d'occhio di individuare quello che cerchi e di apportare modifiche senza
sapere nulla del 99,999999% del restante codice sorgente
Non conosco.
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 :(
Faccio prima a creare una VM "liscia" con solo il minimo necessario per
rigenerare l'errore.
--
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
Reply to: