Re: Segfaults
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
Re: Segfaults
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
Re: Segfaults
Il 12/10/2021 19:43, Davide Prina ha scritto:
quando installi un pacchetto .deb viene eseguito come root e come root
può fare di tutto...
Lo so. Per questo usiamo solo repository verificati e "affidabili". I
ppa mi danno i brividi... :)
ldd lista solo le lib necessarie, non quelle opzionali o i "plugin".
no, ldd indica tutte le librerie linkate dinamicamente
Non può.
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.
Sono passati diversi anni da quando ho usato opzioni avanzate di link,
ma questa non la sapevo. Per come la sapevo io, se ld non trova una lib
non si riesce a lanciare l'eseguibile.
Per caricare lib opzionali c'è, appunto, ldopen: prende un filename che
potrebbe essere generato dinamicamente ("carica tutti i .so presenti in
questa cartella") e lo mappa in memoria. Ma ldd fa un'analisi statica
del file e non può sapere quali file verranno caricati da ldopen.
==746909== Address 0x0 is not stack'd, malloc'd or (recently) free'd
questo errore non l'ho mai incontrato prima.
Un normalissimo NULL pointer dereference, direi :)
Apri un bug su libopenblas0, segnala come riprodurlo, installando
octave, ... e riportando questo come risultato dell'esecuzione di octave
Non è così semplice.
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).
Probabilmente la condizione per il while alla 2791 dovrebbe essere
relativa a *func, non a func...
Certo che comunque qualcosa non mi torna: se metto la -serial invece
della -pthread, senza cambiare altro, octave funziona...
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 :(
Magari mi limito a segnalare la cosa al maintainer. Purtroppo è un
sistema di produzione e non posso fare troppi test :(
--
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
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
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 (0x7ffef04ec000) libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x7fc3e75fa000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7fc3e742d000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7fc3e7413000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fc3e73f1000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fc3e722c000) libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x7fc3e7201000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fc3e71f9000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fc3e70b5000) /lib64/ld-linux-x86-64.so.2 (0x7fc3e776c000) libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x7fc3e70b) libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x7fc3e6eaa000) libbsd.so.0 => /usr/lib/x86_64-linux-gnu/libbsd.so.0 (0x7fc3e6e93000) libmd.so.0 => /usr/lib/x86_64-linux-gnu/libmd.so.0 (0x7fc3e6e84000) 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
Re: Segfaults
è 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. Quoto poco o meglio elimino poche cose che non fanno più parte del discorso per far capire anche a chi non ha letto la risposta intermedia. On 11/10/21 09:03, Diego Zuccato wrote: Il 08/10/2021 18:37, Davide Prina ha scritto: deb https://repo.pbis.beyondtrust.com/apt pbiso main questo potrebbe esserne la causa, se ha installato qualche libreria. Non mi pare. Sarebbe meglio evitare di aggiungere repository terzi, se si necessita di un applicativo particolare che non c'è in Debian l'ottimale sarebbe installarselo in locale o se non si può in otp facendo attenzione che non vada a sovrascrivere librerie o altro di sistema Sto cercando una soluzione per eliminare PBIS (ex Likewise-open), ma purtroppo ho necessità di autenticare utenti in un AD sul quale non ho controllo. Prima usavo winbind, ma era instabile. Adesso con PBIS ho sempre problemi di UID e GID in conflitto (più di 200k utenti e 800k gruppi, con range fissati per domini molto più piccoli!). La soluzione potrebbe essere Kerberos per l'autenticazione più un LDAP per l'autorizzazione e gli attributi. Io lo commenterei e verificherei quali pacchetti sono stati installati da questo... puoi usare i comandi che ti avevo indicato: 1) rintracci i pacchetti installati non più presenti nei repository 2) commenti repo.pbis.beyondtrust.com 3) esegui # apt update 4) riesegui il punto 1 e vedi le differenze Ho usato un sistema più drastico: - 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 - reinstallato octave di nuovo segfault. Uff! Eppure venerdì *con* pbis e *senza* cdo funzionava... Qua ci esco pazzo. Mi sa che sia qualcosa nelle lib mpi. Però io ho octave installato, ma octave-linear-algebra no... potresti anche provare a rimuoverli entrambi e installare solo octave Fatto. Ma non va. # apt update; apt upgrade; apt dist-upgrade Il problema c'è stato proprio al termine dell'aggiornamento :) sì, intendevo rimuovi i pacchetti che non riesci ad installare e rifai quei comandi per assicurarti che il tuo sistema sia aggiornato... se non lo era, allora dopo l'aggiornamento riprovi ad installare octave Altra prova: - disabilitati repo pbis e backports - apt remove octave cdo libopenblas0 libopenblas0-pthread - apt autoremove - update + full-upgrade - apt-show-versions -i - # apt-show-versions | grep available pbis-open:amd64 9.1.0.551 installed: No available version in archive pbis-open-upgrade:amd64 9.1.0.551 installed: No available version in archive [quindi pare non ci fosse nulla da backports e nessuna lib da pbis] ma quando rimuovevi sopra pbis-open, poi rimuoveva anche pbis-open-upgrade? Tieni presente che se installi qualcosa da sistemi terzi gli script di installazione potrebbero modificare file/link di sistema... - apt install octave-linear-algebra [*FUNZIONA!*] - apt install cdo [si porta dietro anche *libopenblas0* e *libopenblas0-pthread*] - octave va in segfault La mia conclusione è che octave tenti di usare (male?) libblas0-pthread, o che ci sia un bug in libblas0-pthread quando viene usata da octave. 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 cosa riportano i seguenti comandi? $ ls -l /usr/lib/x86_64-linux-gnu/libopenblas.so.0 lrwxrwxrwx 1 root root 51 11 ott 08.42 /usr/lib/x86_64-linux-gnu/libopenblas.so.0 -> /etc/alternatives/libopenblas.so.0-x86_64-linux-gnu $ dpkg -S /usr/lib/x86_64-linux-gnu/libopenblas.so.0 dpkg-query: nessun percorso corrispondente a /usr/lib/x86_64-linux-gnu/libopenblas.so.0 $ dpkg -l | grep "libopenblas0-openmp\|libjulia" ii libjulia1 1.5.3+dfsg-3 amd64 high-performance programming language for technical computing (runtime library) o è un link simbolico creato da qualche script di postream o è stata installata da un repository terzo, come quello indicato sopra. Nel secondo caso è possibile che rimuovendo il pacchetto terzo che la installa risolvi. E' un link creato automaticamente da update-alternatives: update-alternatives --config libblas.so.3-x86_64-linux-gnu Sono disponibili 3 scelte per l'alternativa libblas.so.3-x86_64-linux-gnu (che fornisce /usr/lib/x86_64-linux-gnu/libblas.so.3). Selezione Percorso Priorità Stato * 0 /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3 100 modalità automatica 1
Re: Segfaults
On 08/10/21 08:47, Diego Zuccato wrote: Il 07/10/2021 20:42, Davide Prina ha scritto: root@str957-cluster:~# cat /etc/apt/sources.list deb https://security.debian.org/debian-security bullseye-security main contrib non-free questo lo cambierei con: deb https://deb.debian.org/debian-security bullseye-security main contrib non-free deb http://ftp.debian.org/debian bullseye main contrib non-free questo ti consiglio di cambiarlo con: deb https://deb.debian.org/debian bullseye main contrib non-free uno usi https ed eviti possibili attacchi MTM e due ti sceglie lui un repository e non ne hai uno fisso root@str957-cluster:~# cat /etc/apt/sources.list.d/* deb http://deb.debian.org/debian/ bullseye-backports main ma hai installato qualcosa dai backport? deb https://repo.pbis.beyondtrust.com/apt pbiso main questo potrebbe esserne la causa, se ha installato qualche libreria. Sarebbe meglio evitare di aggiungere repository terzi, se si necessita di un applicativo particolare che non c'è in Debian l'ottimale sarebbe installarselo in locale o se non si può in otp facendo attenzione che non vada a sovrascrivere librerie o altro di sistema Io lo commenterei e verificherei quali pacchetti sono stati installati da questo... puoi usare i comandi che ti avevo indicato: 1) rintracci i pacchetti installati non più presenti nei repository 2) commenti repo.pbis.beyondtrust.com 3) esegui # apt update 4) riesegui il punto 1 e vedi le differenze * se c'è qualcosa non completamente configurato # apt -f install Solo octave e octave-linear-algebra ma hai provato a rimuovere entrambi e installare soltanto octave-linear-algebra se per caso questo funziona... o magari è questo che ti da problemi. Però io ho octave installato, ma octave-linear-algebra no... potresti anche provare a rimuoverli entrambi e installare solo octave * aggiornerei il sistema, dopo aver eventualmente aggiustato i repository # apt update; apt upgrade; apt dist-upgrade Il problema c'è stato proprio al termine dell'aggiornamento :) sì, intendevo rimuovi i pacchetti che non riesci ad installare e rifai quei comandi per assicurarti che il tuo sistema sia aggiornato... se non lo era, allora dopo l'aggiornamento riprovi ad installare octave * guarderei nei log apri un xterm ed esegui (per poi fermarlo basta Ctrl-C) $ journalctl -f ott 08 07:07:05 str957-cluster kernel: octave-cli[2403836]: segfault at 0 ip sp 7fe490be7a58 error 14 in octave-cli[55dd1d6ff000+2000] ott 08 07:07:05 str957-cluster kernel: Code: Unable to access opcode bytes at RIP 0xffd6. questo potrebbe essere causato da un problema software risolvibile con un check del filesystem, però, da quello che ho capito dovresti avere altre righe dopo quest'ultima o un bug del filesystem che usi. Ho visto che c'è una patch per raisefs: https://lore.kernel.org/all/20210702040743.1918552-1-yuku...@huawei.com/ Ma forse ci sono arrivato. In parte, almeno. Il backtrace con l'eseguibile corretto mi dà: [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/usr/bin/octave-cli --silent --no-history --no-init-file --no-window-system --e'. [...] /usr/lib/x86_64-linux-gnu/libopenblas.so.0 ma questa libreria non sembra esistere in Debian stable in quella posizione: https://packages.debian.org/search?searchon=contents=libopenblas.so.0=path=stable=any cosa riportano i seguenti comandi? $ ls -l /usr/lib/x86_64-linux-gnu/libopenblas.so.0 $ dpkg -S /usr/lib/x86_64-linux-gnu/libopenblas.so.0 $ dpkg -l | grep "libopenblas0-openmp\|libjulia" o è un link simbolico creato da qualche script di postream o è stata installata da un repository terzo, come quello indicato sopra. Nel secondo caso è possibile che rimuovendo il pacchetto terzo che la installa risolvi. Se invece è un link simbolico arriva fino al file vero e verifica in quale pacchetto è presente Se rimuovo sia octave che cdo e relative dipendenze, reinstallando octave non ho più il segfault. Che però riappare se reinstallo cdo. però il problema potrebbe essere la libreria sopra riportata root@str957-cluster:~# apt install cdo [...] Selezionato il pacchetto libopenblas0-pthread:amd64 non precedentemente selezionato. ecco qui la libreria incriminata root@str957-cluster:~# octave X11 connection rejected because of wrong authentication. octave: unable to open X11 DISPLAY octave: disabling GUI features però non puoi farmi partire octave da root... devi farlo partire da utente... Errore di segmentazione (core dump creato) questo potrebbe essere dovuto all'uso di una libreria non corretta... o meglio all'uso della libreria in posizione non corretta $ ldd /usr/bin/octave ma se vai partire cdo funziona? (non l'ho installato ho guardato con apt-file i file che installa) $ cdo $ cdi che libreria usa $ ldd /usr/bin/cdo $ ldd /usr/bin/cdi Ciao Davide --
Re: Segfaults
On 07/10/21 20:42, Davide Prina wrote: Dopo l'aggiornamnto a bullseye ho [...] segfault. Il primo è all'installazione di octave: la configurazione fallisce. ci ho ripensato, il problema potrebbe essere un errore logico su disco (se non è un errore hardware su disco). Penso che andando a leggere una libreria danneggiata esegua qualcosa di non "voluto". Esegui un check del disco e verifica cosa corregge, segnandoti i nomi dei file impattati. per trovare in che pacchetto è il file trovato: $ dpkg -S NOMEFILE_DANNEGGIATO e reinstalli il pacchetto # apt install --reinstall NOMEPACCHETTO Ciao Davide -- What happened in 2013 couldn't have happened without free software (He credited free software for his ability to help disclose the U.S. government's far-reaching surveillance projects). Edward Snowden
Re: Segfaults
On 06/10/21 11:22, Diego Zuccato wrote: Dopo l'aggiornamnto a bullseye ho [...] segfault. Il primo è all'installazione di octave: la configurazione fallisce. la prima cosa da fare in questi casi è verificare se qualcuno ha avuto il tuo stesso problema e ha già aperto un bug report: https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=octave ma vedo che hai già aperto tu un bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995450 però nella tua segnalazione ti viene indicato: warning: core file may not match specified executable file. [...] Core was generated by `/usr/bin/octave-cli --silent --no-history --no-init-file --no-window-system --e'. inoltre hai visto questo bug report? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992405 Ho provato a fare il purge (anche di liboctave8) e la reinstallazione, ma il risultato non cambia. Cos'altro posso provare a fare? puoi installare i simboli di debug e riprovare, qui trovi un po' di info su come procedere: https://wiki.debian.org/HowToGetABacktrace Il secondo è con python-numpy: appena eseguo un "import numpy" ottengo un segfault. anche qui vedo che hai aperto un bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995454 L'errore non è solo col mio utente, ma con tutti. Qualcuno ha idea di come possa debuggare? io verificherei * che repository usi: $ cat /etc/apt/sources.list $ cat /etc/apt/sources.list.d/* * se c'è qualcosa non completamente configurato # apt -f install * aggiornerei il sistema, dopo aver eventualmente aggiustato i repository # apt update; apt upgrade; apt dist-upgrade * se hai installato pacchetti non più presenti nei repository # apt install apt-show-versions # apt-show-versions -i $ apt-show-versions | grep available o quest'altro # apt install apt-forktracer $ apt-forktracer * guarderei nei log apri un xterm ed esegui (per poi fermarlo basta Ctrl-C) $ journalctl -f riesegui le operazioni che generano i segfault e guarda se nei log ti mette qualcosa di interessante * potrebbe eanche essere un problema hardware del disco o della RAM (anche se per la RAM mi sembra davvero strano con questo comportamento). Propenderei di più per il disco Prova a fare un check del disco Ciao Davide -- Database: http://www.postgresql.org GNU/Linux User: 302090: http://counter.li.org Non autorizzo la memorizzazione del mio indirizzo su outlook
Re: Segfaults
se hai il core dump puoi provare a debaggare quello con gdb, almeno per vedere da cosa nasce il problema. Altra prova, considerando che più di un programma ti genera questo problema, vedere che librerie caricano prima l'installazione di octave e successivamente python-numpy e vedere quali libreria in comune hanno. E' probabile che l'installazione di octave, sotto sotto, richiami python. Ciao e buona fortuna Il giorno mer 6 ott 2021 alle ore 14:59 Diego Zuccato < diego.zucc...@unibo.it> ha scritto: > Ciao a tutti. > > Dopo l'aggiornamnto a bullseye ho due problemi che potrebbero essere o > meno collegati. In entrambi i casi si tratta di un segfault. > > Il primo è all'installazione di octave: la configurazione fallisce. Ho > provato a fare il purge (anche di liboctave8) e la reinstallazione, ma > il risultato non cambia. Cos'altro posso provare a fare? > > Il secondo è con python-numpy: appena eseguo un "import numpy" ottengo > un segfault. > diego.zuccato@str957-cluster:~$ python3 > Python 3.9.2 (default, Feb 28 2021, 17:03:44) > [GCC 10.2.1 20210110] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> import numpy > Errore di segmentazione (core dump creato) > > L'errore non è solo col mio utente, ma con tutti. Qualcuno ha idea di > come possa debuggare? > > Grazie. > > -- > 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 > > -- Giancarlo Martini (Replace 'AAA' con '@') mailto:giancarlo.firAAAgmail.com
