Re: Segfaults

1 view
Skip to first unread message

Giancarlo Martini

unread,
Oct 6, 2021, 12:10:03 PMOct 6
to
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....@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

Davide Prina

unread,
Oct 7, 2021, 2:50:03 PMOct 7
to
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

Davide Prina

unread,
Oct 7, 2021, 5:10:03 PMOct 7
to
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

Davide Prina

unread,
Oct 8, 2021, 12:40:03 PMOct 8
to
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 0000000000000000 sp 00007fe490be7a58 error 14 in
> octave-cli[55dd1d6ff000+2000]
> ott 08 07:07:05 str957-cluster kernel: Code: Unable to access opcode
> bytes at RIP 0xffffffffffffffd6.

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.1...@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&keywords=libopenblas.so.0&mode=path&suite=stable&arch=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
--
Motivi per non comprare/usare ms-windows7:
http://windows7sins.org/

Davide Prina

unread,
Oct 11, 2021, 2:20:02 PMOct 11
to
è 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            /usr/lib/x86_64-linux-gnu/atlas/libblas.so.3   35
> modalità manuale
>   2            /usr/lib/x86_64-linux-gnu/blas/libblas.so.3   10
> modalità manuale
>   3            /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3
>   100       modalità manuale
>
>> Se invece è un link simbolico arriva fino al file vero e verifica in
>> quale pacchetto è presente
> Fatto :)
>
>> però non puoi farmi partire octave da root... devi farlo partire da
>> utente...
> Quando la libopenblas0-pthread non è installata, non ha problemi. E la
> configurazione lo lancia da root. Comunque anche da utente fa uguale.

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.

>> ma se vai partire cdo funziona? (non l'ho installato ho guardato con
>> apt-file i file che installa)
>> $ cdo
>> $ cdi
> In entrambi i casi ottengo l'help.
> Quindi (senza conoscerlo) posso dire che "funziona". Per lo meno non va
> in errore immediatamente.
>
>> che libreria usa
>> $ ldd /usr/bin/cdo
> # ldd /usr/bin/cdo
>         linux-vdso.so.1 (0x00007ffdb89a8000)
>         libcdi.so.0 => /usr/lib/x86_64-linux-gnu/libcdi.so.0
> (0x00007f51f193a000)
>         libMagPlus.so.3 => /usr/lib/x86_64-linux-gnu/libMagPlus.so.3
> (0x00007f51f0d7b000)
>         libproj.so.19 => /usr/lib/x86_64-linux-gnu/libproj.so.19
> (0x00007f51f0a08000)
>         libfftw3.so.3 => /usr/lib/x86_64-linux-gnu/libfftw3.so.3
> (0x00007f51f0801000)
>         libudunits2.so.0 => /usr/lib/x86_64-linux-gnu/libudunits2.so.0
> (0x00007f51f07e1000)
>         libnetcdf.so.18 => /usr/lib/x86_64-linux-gnu/libnetcdf.so.18
> (0x00007f51f06b0000)
>         libhdf5_serial.so.103 =>
> /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.103 (0x00007f51f032d000)
>         libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x00007f51f030b000)
>         libcurl-gnutls.so.4 =>
> /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 (0x00007f51f0273000)
>         libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> (0x00007f51f00a6000)
>         libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f51eff62000)
>         libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1
> (0x00007f51eff22000)
>         libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
> (0x00007f51eff06000)
>         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f51efd41000)
>         /lib64/ld-linux-x86-64.so.2 (0x00007f51f212f000)
>         libeccodes.so.0 => /usr/lib/x86_64-linux-gnu/libeccodes.so.0
> (0x00007f51efa75000)
>         libsz.so.2 => /usr/lib/x86_64-linux-gnu/libsz.so.2
> (0x00007f51efa70000)
>         libterralib.so.3 => /usr/lib/x86_64-linux-gnu/libterralib.so.3
> (0x00007f51ef6c1000)
>         libodccore.so.0d => /usr/lib/x86_64-linux-gnu/libodccore.so.0d
> (0x00007f51ef58d000)
>         libQt5Widgets.so.5 =>
> /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 (0x00007f51eef01000)
>         libgeotiff.so.5 => /usr/lib/x86_64-linux-gnu/libgeotiff.so.5
> (0x00007f51eeecb000)
>         libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1
> (0x00007f51eee9c000)
>         libpangocairo-1.0.so.0 =>
> /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007f51eee8b000)
>         libpango-1.0.so.0 =>
> /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007f51eee39000)
>         libglib-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
> (0x00007f51eed0a000)
>         libcairo.so.2 => /usr/lib/x86_64-linux-gnu/libcairo.so.2
> (0x00007f51eebe3000)
>         libeckit.so.0d => /usr/lib/x86_64-linux-gnu/libeckit.so.0d
> (0x00007f51ee954000)
>         libQt5Gui.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
> (0x00007f51ee292000)
>         libQt5Core.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
> (0x00007f51edd47000)
>         libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
> (0x00007f51edc04000)
>         libtiff.so.5 => /usr/lib/x86_64-linux-gnu/libtiff.so.5
> (0x00007f51edb7e000)
>         libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
> (0x00007f51edb76000)
>         libhdf5_serial_hl.so.100 =>
> /usr/lib/x86_64-linux-gnu/libhdf5_serial_hl.so.100 (0x00007f51edb51000)
>         libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f51edb34000)
>         libnghttp2.so.14 => /usr/lib/x86_64-linux-gnu/libnghttp2.so.14
> (0x00007f51edb07000)
>         libidn2.so.0 => /usr/lib/x86_64-linux-gnu/libidn2.so.0
> (0x00007f51edae6000)
>         librtmp.so.1 => /usr/lib/x86_64-linux-gnu/librtmp.so.1
> (0x00007f51edac5000)
>         libssh2.so.1 => /usr/lib/x86_64-linux-gnu/libssh2.so.1
> (0x00007f51eda90000)
>         libpsl.so.5 => /usr/lib/x86_64-linux-gnu/libpsl.so.5
> (0x00007f51eda7c000)
>         libnettle.so.8 => /usr/lib/x86_64-linux-gnu/libnettle.so.8
> (0x00007f51eda34000)
>         libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30
> (0x00007f51ed834000)
>         libgssapi_krb5.so.2 =>
> /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f51ed7e1000)
>         libldap_r-2.4.so.2 =>
> /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f51ed789000)
>         liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2
> (0x00007f51ed778000)
>         libbrotlidec.so.1 =>
> /usr/lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007f51ed76a000)
>         libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16
> (0x00007f51ed730000)
>         libaec.so.0 => /usr/lib/x86_64-linux-gnu/libaec.so.0
> (0x00007f51ed727000)
>         libopenjp2.so.7 => /usr/lib/x86_64-linux-gnu/libopenjp2.so.7
> (0x00007f51ed6c8000)
>         libjpeg.so.62 => /usr/lib/x86_64-linux-gnu/libjpeg.so.62
> (0x00007f51ed644000)
>         libeckit_sql.so.0d =>
> /usr/lib/x86_64-linux-gnu/libeckit_sql.so.0d (0x00007f51ed4da000)
>         libpangoft2-1.0.so.0 =>
> /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007f51ed4c1000)
>         libgobject-2.0.so.0 =>
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f51ed467000)
>         libfontconfig.so.1 =>
> /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f51ed41f000)
>         libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
> (0x00007f51ed241000)
>         libfribidi.so.0 => /usr/lib/x86_64-linux-gnu/libfribidi.so.0
> (0x00007f51ed225000)
>         libthai.so.0 => /usr/lib/x86_64-linux-gnu/libthai.so.0
> (0x00007f51ed21a000)
>         libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0
> (0x00007f51ed132000)
>         libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3
> (0x00007f51ed0bf000)
>         libpixman-1.so.0 => /usr/lib/x86_64-linux-gnu/libpixman-1.so.0
> (0x00007f51ed012000)
>         libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6
> (0x00007f51ecf4f000)
>         libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0
> (0x00007f51ecf4a000)
>         libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1
> (0x00007f51ecf1f000)
>         libxcb-render.so.0 =>
> /usr/lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007f51ecf10000)
>         libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1
> (0x00007f51ecd06000)
>         libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6
> (0x00007f51ecbc1000)
>         libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6
> (0x00007f51ecbac000)
>         libsnappy.so.1 => /usr/lib/x86_64-linux-gnu/libsnappy.so.1
> (0x00007f51ecba1000)
>         librsync.so.2 => /usr/lib/x86_64-linux-gnu/librsync.so.2
> (0x00007f51ecb92000)
>         liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1
> (0x00007f51ecb6f000)
>         libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0
> (0x00007f51ecb5c000)
>         libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
> (0x00007f51ec866000)
>         libxxhash.so.0 => /usr/lib/x86_64-linux-gnu/libxxhash.so.0
> (0x00007f51ec84d000)
>         librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
> (0x00007f51ec842000)
>         libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1
> (0x00007f51ec7bb000)
>         libmd4c.so.0 => /usr/lib/x86_64-linux-gnu/libmd4c.so.0
> (0x00007f51ec7a9000)
>         libdouble-conversion.so.3 =>
> /usr/lib/x86_64-linux-gnu/libdouble-conversion.so.3 (0x00007f51ec790000)
>         libicui18n.so.67 => /usr/lib/x86_64-linux-gnu/libicui18n.so.67
> (0x00007f51ec48a000)
>         libicuuc.so.67 => /usr/lib/x86_64-linux-gnu/libicuuc.so.67
> (0x00007f51ec2a1000)
>         libpcre2-16.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-16.so.0
> (0x00007f51ec217000)
>         libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1
> (0x00007f51ec13c000)
>         libwebp.so.6 => /usr/lib/x86_64-linux-gnu/libwebp.so.6
> (0x00007f51ec0d3000)
>         liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5
> (0x00007f51ec0a9000)
>         libjbig.so.0 => /usr/lib/x86_64-linux-gnu/libjbig.so.0
> (0x00007f51ebe9b000)
>         libdeflate.so.0 => /usr/lib/x86_64-linux-gnu/libdeflate.so.0
> (0x00007f51ebe7f000)
>         libunistring.so.2 =>
> /usr/lib/x86_64-linux-gnu/libunistring.so.2 (0x00007f51ebcfd000)
>         libhogweed.so.6 => /usr/lib/x86_64-linux-gnu/libhogweed.so.6
> (0x00007f51ebcb4000)
>         libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10
> (0x00007f51ebc31000)
>         libgcrypt.so.20 => /usr/lib/x86_64-linux-gnu/libgcrypt.so.20
> (0x00007f51ebb11000)
>         libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0
> (0x00007f51eb9dd000)
>         libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6
> (0x00007f51eb9c7000)
>         libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3
> (0x00007f51eb8ed000)
>         libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3
> (0x00007f51eb8bd000)
>         libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2
> (0x00007f51eb8b5000)
>         libkrb5support.so.0 =>
> /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f51eb8a6000)
>         libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2
> (0x00007f51eb88c000)
>         libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2
> (0x00007f51eb86f000)
>         libbrotlicommon.so.1 =>
> /usr/lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007f51eb84c000)
>         libffi.so.7 => /usr/lib/x86_64-linux-gnu/libffi.so.7
> (0x00007f51eb83e000)
>         libuuid.so.1 => /usr/lib/x86_64-linux-gnu/libuuid.so.1
> (0x00007f51eb835000)
>         libgmodule-2.0.so.0 =>
> /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007f51eb82f000)
>         libmount.so.1 => /usr/lib/x86_64-linux-gnu/libmount.so.1
> (0x00007f51eb7d2000)
>         libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1
> (0x00007f51eb7a6000)
>         libdatrie.so.1 => /usr/lib/x86_64-linux-gnu/libdatrie.so.1
> (0x00007f51eb79c000)
>         libgraphite2.so.3 =>
> /usr/lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007f51eb76e000)
>         libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6
> (0x00007f51eb769000)
>         libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6
> (0x00007f51eb563000)
>         libb2.so.1 => /usr/lib/x86_64-linux-gnu/libb2.so.1
> (0x00007f51eb544000)
>         libGLdispatch.so.0 =>
> /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f51eb48c000)
>         libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0
> (0x00007f51eb456000)
>         libicudata.so.67 => /usr/lib/x86_64-linux-gnu/libicudata.so.67
> (0x00007f51e993d000)
>         libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0
> (0x00007f51e9917000)
>         libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1
> (0x00007f51e9910000)
>         libblkid.so.1 => /usr/lib/x86_64-linux-gnu/libblkid.so.1
> (0x00007f51e98bd000)
>         libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0
> (0x00007f51e9825000)
>         libbsd.so.0 => /usr/lib/x86_64-linux-gnu/libbsd.so.0
> (0x00007f51e980e000)
>         libmd.so.0 => /usr/lib/x86_64-linux-gnu/libmd.so.0
> (0x00007f51e9801000)
>
>> $ ldd /usr/bin/cdi# ldd /usr/bin/cdi
>         linux-vdso.so.1 (0x00007ffd5c0c5000)
>         libcdi.so.0 => /usr/lib/x86_64-linux-gnu/libcdi.so.0
> (0x00007f9108716000)
>         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9108551000)
>         libeccodes.so.0 => /usr/lib/x86_64-linux-gnu/libeccodes.so.0
> (0x00007f9108285000)
>         libnetcdf.so.18 => /usr/lib/x86_64-linux-gnu/libnetcdf.so.18
> (0x00007f9108154000)
>         libsz.so.2 => /usr/lib/x86_64-linux-gnu/libsz.so.2
> (0x00007f910814f000)
>         libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f910800b000)
>         libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x00007f9107fe7000)
>         /lib64/ld-linux-x86-64.so.2 (0x00007f9108854000)
>         libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16
> (0x00007f9107fad000)
>         libaec.so.0 => /usr/lib/x86_64-linux-gnu/libaec.so.0
> (0x00007f9107fa4000)
>         libopenjp2.so.7 => /usr/lib/x86_64-linux-gnu/libopenjp2.so.7
> (0x00007f9107f47000)
>         libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1
> (0x00007f9107f07000)
>         libhdf5_serial_hl.so.100 =>
> /usr/lib/x86_64-linux-gnu/libhdf5_serial_hl.so.100 (0x00007f9107ee2000)
>         libhdf5_serial.so.103 =>
> /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.103 (0x00007f9107b5f000)
>         libcurl-gnutls.so.4 =>
> /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 (0x00007f9107ac7000)
>         libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f9107aaa000)
>         libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
> (0x00007f9107aa4000)
>         libnghttp2.so.14 => /usr/lib/x86_64-linux-gnu/libnghttp2.so.14
> (0x00007f9107a77000)
>         libidn2.so.0 => /usr/lib/x86_64-linux-gnu/libidn2.so.0
> (0x00007f9107a54000)
>         librtmp.so.1 => /usr/lib/x86_64-linux-gnu/librtmp.so.1
> (0x00007f9107a35000)
>         libssh2.so.1 => /usr/lib/x86_64-linux-gnu/libssh2.so.1
> (0x00007f9107a00000)
>         libpsl.so.5 => /usr/lib/x86_64-linux-gnu/libpsl.so.5
> (0x00007f91079ec000)
>         libnettle.so.8 => /usr/lib/x86_64-linux-gnu/libnettle.so.8
> (0x00007f91079a4000)
>         libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30
> (0x00007f91077a4000)
>         libgssapi_krb5.so.2 =>
> /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f910774f000)
>         libldap_r-2.4.so.2 =>
> /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f91076f9000)
>         liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2
> (0x00007f91076e8000)
>         libbrotlidec.so.1 =>
> /usr/lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007f91076da000)
>         libunistring.so.2 =>
> /usr/lib/x86_64-linux-gnu/libunistring.so.2 (0x00007f9107558000)
>         libhogweed.so.6 => /usr/lib/x86_64-linux-gnu/libhogweed.so.6
> (0x00007f910750d000)
>         libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10
> (0x00007f910748c000)
>         libgcrypt.so.20 => /usr/lib/x86_64-linux-gnu/libgcrypt.so.20
> (0x00007f910736c000)
>         libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0
> (0x00007f9107238000)
>         libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6
> (0x00007f9107222000)
>         libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3
> (0x00007f9107146000)
>         libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3
> (0x00007f9107116000)
>         libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2
> (0x00007f9107110000)
>         libkrb5support.so.0 =>
> /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f9107101000)
>         libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2
> (0x00007f91070e7000)
>         libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2
> (0x00007f91070ca000)
>         libbrotlicommon.so.1 =>
> /usr/lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007f91070a5000)
>         libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0
> (0x00007f910707f000)
>         libffi.so.7 => /usr/lib/x86_64-linux-gnu/libffi.so.7
> (0x00007f9107073000)
>         libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1
> (0x00007f910706c000)
>
> 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

>
> Tra l'altro, direi che a questo punto posso confermare che l'errore con
> python è collegato:
> # 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)

$ 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


> # gdb /usr/bin/python3 core
> GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
> Copyright (C) 2021 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <https://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
>     <http://www.gnu.org/software/gdb/documentation/>.
>
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /usr/bin/python3...
> (No debugging symbols found in /usr/bin/python3)
> [New LWP 314439]
> [New LWP 314432]
> [New LWP 314434]
> [New LWP 314435]
> [New LWP 314433]
> [New LWP 314436]
> [New LWP 314438]
> [New LWP 314437]
> [New LWP 314440]
> [New LWP 314429]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `python3'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x0000000000000000 in ?? ()
> [Current thread is 1 (Thread 0x7f6e9d75e700 (LWP 314439))]
> (gdb) bt
> #0  0x0000000000000000 in ?? ()
> #1  0x00007f6ed15c9709 in blas_memory_alloc () from
> /usr/lib/x86_64-linux-gnu/libopenblas.so.0
> #2  0x00007f6ed15c9f04 in ?? () from
> /usr/lib/x86_64-linux-gnu/libopenblas.so.0
> #3  0x00007f6ed42e1ea7 in start_thread (arg=<optimized out>) at
> pthread_create.c:477
> #4  0x00007f6ed4074def in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
>
> 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.

In realtà prima serve sapere in che sorgente c'è il problema e quindi
bisogna installare i simboli di debug:

aggiungendo in /etc/apt/sources.list
deb https://deb.debian.org/debian-debug/ stable-debug main

aggiornando la chace:
# apt update

e installando i simboli di debug del pacchetto che ti indica come
contenente una delle chiamate al problema per arrivare all'errore.

A questo punto rieseguendo l'istruzione con valgrind ti riporta il nome
del sorgente e la riga di quel sorgente.

Ad esempio puoi vedere questo bug report che ho segnalato e in cui ho
usato valgrind per trovare il bug: individuare la libreria e individuare
l'istruzione della libreria che causava il problema
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975658

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

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

Davide Prina

unread,
Oct 12, 2021, 1:50:02 PMOct 12
to
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/

Davide Prina

unread,
Oct 13, 2021, 3:50:02 PMOct 13
to
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
Reply all
Reply to author
Forward
0 new messages