search

Qucs / qucs

Qucs Project official mirror
http://qucs.sourceforge.net/
GNU General Public License v2.0
1.16k stars 213 forks source link

Qucs crashing as soon as any component is added. #1009

Closed rolimans closed 4 years ago

rolimans commented 4 years ago

As soon as I add any component to a sketch file (eg: a resistor) the program crashes. The log of the execution follows:

Unable to load library icui18n "Cannot load library icui18n: (icui18n: cannot open shared object file: No such file or directory)" 
Warning: QVariant::save: unable to save type 261.
[1]    13495 segmentation fault (core dumped)  qucs

I'm using qucs 0.0.20 builded from source in Arch Linux 64 bits. PS: icui and icui32bit are both installed.

oxmon-2500 commented 4 years ago

try following:

sudo find / -name "libicui18n*"
strace -e trace=all qucs &>qucs_strace.log
grep libicui18n qucs_strace.log

and post the output of grep.

perhaps 

export LD_LIBRARY_PATH=path_to_libicu18n

will help

rolimans commented 4 years ago

try following:

sudo find / -name "libicui18n*"
strace -e trace=all qucs &>qucs_strace.log
grep libicui18n qucs_strace.log

and post the output of grep.

perhaps

export LD_LIBRARY_PATH=path_to_libicu18n

will help

Strace log is:

openat(AT_FDCWD, "/usr/lib/tls/haswell/x86_64/libicui18n.so.64", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/tls/haswell/libicui18n.so.64", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/tls/x86_64/libicui18n.so.64", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/tls/libicui18n.so.64", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/haswell/x86_64/libicui18n.so.64", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/haswell/libicui18n.so.64", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/x86_64/libicui18n.so.64", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/libicui18n.so.64", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/libicui18n", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

My libraries are at:

/usr/lib/libicui18n.so
/usr/lib/libicui18n.so.67.1
/usr/lib/libicui18n.so.67

/usr/lib32/libicui18n.so
/usr/lib32/libicui18n.so.67.1
/usr/lib32/libicui18n.so.67

It seems qucs is looking for the wrong library extension (.so.64). Why doesn't it just look for .so?

felix-salfelder commented 4 years ago

On Tue, Jun 09, 2020 at 12:29:58PM -0700, Eduardo Amaral wrote:

My libraries are at:

/usr/lib/libicui18n.so
/usr/lib/libicui18n.so.67.1
/usr/lib/libicui18n.so.67

/usr/lib32/libicui18n.so
/usr/lib32/libicui18n.so.67.1
/usr/lib32/libicui18n.so.67

It seems qucs is looking for the wrong library extension (.so.64). Why doesn't it just look for .so?

Note how *.so is only used during linking. afterwards your program uses the library that you have linked against (c.f. SONAME). the general approach is, not to delete a (shared) library after linking against it.

Now, I am not exactly sure why qucs starts at all, given that a library is not there. maybe something else is loaded dynamically, and is trying to use the library, which has disappeared unexpectedly. broken Qt installation? (need more context).

rolimans commented 4 years ago

It's not me the only one to have this problem in Arch Linux. In fact I was advised to create this issue in the AUR forum. I also don't understend why the program launches at all. And I have no idea if the crashes are related to the missing library. Still have not figred out how to make qucs find libcui18n

oxmon-2500 commented 4 years ago

On my centos8 system it looks like:

/usr/local/Trolltech/Qt-4.8.7/lib/libicui18n.so.60 ... No such file or directory
/lib64/libicui18n.so.60", O_RDONLY|O_CLOEXEC) = 3
/usr/local/Trolltech/Qt-4.8.7/lib/libicuuc.so.60 ... No such file or directory
/lib64/libicuuc.so.60", O_RDONLY|O_CLOEXEC) = 3
/usr/local/Trolltech/Qt-4.8.7/lib/libicudata.so.60 ... No such file or directory
/lib64/libicudata.so.60", O_RDONLY|O_CLOEXEC) = 3

I think its a problem of Qt, which tries to loads the specific library dynamically.

The hack (not tested)

mkdir ~/libhack
ln -s /usr/lib/libicui18n.so.67.1 ~/libhack/libicui18n.so.64
ln -s /usr/lib/libicuuc.so.67.1 ~/libhack/libicuuc.so.64
ln -s /usr/lib/libicudata.so.67.1 ~/libhack/libicudata.so.64
export LD_LIBRARY_PATH=~/libhack:$LD_LIBRARY_PATH
qucs

will probably do the trick, presumed the version 67 is downwards compatible with version 64

rolimans commented 4 years ago

Tried creating a syslink to the libicui18n as @oxmon-2500 said, but it doesn't seem version 67 is backwards compatible. It gives me:

Unable to find symbols in icui18n
Warning: QVariant::save: unable to save type 261.
[1]    7335 segmentation fault (core dumped)  qucs

Also, don't know if it matters but running ldd in qucs binary does not shows libicui18n.

    linux-vdso.so.1 (0x00007ffd7c7d4000)
    libQtScript.so.4 => /usr/lib/libQtScript.so.4 (0x00007f8157d1f000)
    libQtSvg.so.4 => /usr/lib/libQtSvg.so.4 (0x00007f8157cc6000)
    libQt3Support.so.4 => /usr/lib/libQt3Support.so.4 (0x00007f81579c0000)
    libQtGui.so.4 => /usr/lib/libQtGui.so.4 (0x00007f8156e9f000)
    libQtCore.so.4 => /usr/lib/libQtCore.so.4 (0x00007f8156b9c000)
    libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f8156b96000)
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f81569b7000)
    libm.so.6 => /usr/lib/libm.so.6 (0x00007f8156872000)
    libc.so.6 => /usr/lib/libc.so.6 (0x00007f81566ab000)
    libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f8156689000)
    libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f815666f000)
    libz.so.1 => /usr/lib/libz.so.1 (0x00007f8156655000)
    libQtSql.so.4 => /usr/lib/libQtSql.so.4 (0x00007f8156610000)
    libQtXml.so.4 => /usr/lib/libQtXml.so.4 (0x00007f81565c5000)
    libQtNetwork.so.4 => /usr/lib/libQtNetwork.so.4 (0x00007f8156481000)
    libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007f8156358000)
    libpng16.so.16 => /usr/lib/libpng16.so.16 (0x00007f815631e000)
    libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007f815624a000)
    libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007f81561f0000)
    libSM.so.6 => /usr/lib/libSM.so.6 (0x00007f81561e6000)
    libICE.so.6 => /usr/lib/libICE.so.6 (0x00007f81561c9000)
    libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007f81561bc000)
    libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00007f8156175000)
    libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f8156160000)
    libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f815601d000)
    librt.so.1 => /usr/lib/librt.so.1 (0x00007f8156012000)
    /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f81583e9000)
    libssl.so.1.1 => /usr/lib/libssl.so.1.1 (0x00007f8155f82000)
    libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1 (0x00007f8155ca5000)
    libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007f8155c33000)
    libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x00007f8155c1e000)
    libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0 (0x00007f8155b1a000)
    libffi.so.7 => /usr/lib/libffi.so.7 (0x00007f8155b0e000)
    libuuid.so.1 => /usr/lib/libuuid.so.1 (0x00007f8155b05000)
    libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f8155ad5000)
    libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f8155aab000)
    libgraphite2.so.3 => /usr/lib/libgraphite2.so.3 (0x00007f8155a84000)
    libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f8155a7f000)
    libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f8155a77000)
rolimans commented 4 years ago

So I installed an old version of the icu libraries (64), and confirmed that was not the missing library the problem, the program loads fine without a warning, but keeps giving core dumped when trying to add any component.

oxmon-2500 commented 4 years ago

Regarding icui18n library problem the culprit was evidently Qt. Running 

strings /usr/local/Trolltech/Qt-4.8.7/lib/libQtCore.so.4.8.7

there is an output:

icui18n
ucol_open
ucol_close
ucol_strcoll
ucol_open_60
ucol_close_60
ucol_strcoll_60
Unable to load library icuuc
u_strToUpper
u_strToLower
u_strToUpper_60
u_strToLower_60
Unable to load library icui18n
Unable to find symbols in icui18n

Nonetheless there must be some kind of versions salad on the system. What version of Qt is installed on your system?

felix-salfelder commented 4 years ago

On Wed, Jun 10, 2020 at 07:43:44AM -0700, Eduardo Amaral wrote:

So I installed an old version of the icu libraries (64), and confirmed that was not the missing library the problem, the program loads fine without a warning, but keeps giving core dumped when trying to add any component.

so, with the correct library installed it goes from "cannot find library" to just coredump?

it is not entirely clear to me how you could uninstall icu-64 while keeping qt, as it should obviously depend on icu-64. i can sense a bunch of other unsatisfied, broken or missing dependencies.

now from there, assuming all the symlinks are cleaned up, you could try a debugger. or try and rebuild qt, then rebuild qucs. or try and run qucs in a VM or container, with a historic OS providing qt4.

hth

Dantali0n commented 4 years ago

I'm having the exact same issues on Manjaro (Arch).

Rmano commented 4 years ago

It's probably more of a workaround, but you can try to see if the AppImage from https://rmano.github.io/qucsAppImagesBuild/ works. It's minimal (no documentation nor tests nor examples) and it has been build on an Ubuntu 16.04.6 system (where Qt4 is not legacy...).

AlexanderKnapik commented 4 years ago

I've run into this issue many times before all using Manjaro Linux. I'll use the AppImage for now as a workaround.

felix-salfelder commented 4 years ago

It seems this has been traced down to qt incompatibilities and runtime issues. Lacking a solution, we still have a workaround -- thanks to Rmano.