segfault as first action

[Franck78]

well, I guess I'm cursed...

fresh install after 6 hours compilation (just an old test machine) on a fresh Linux mint,
I went to see where Kicad expects the libs because I know this dam installer doesn't do the job... and segfault.

Kicad->Preference->Configure Paths-> BAM

And tell me why by default on the development version, symbols are not ON ?!?!
Another hour to find how to activate the thing and 6 hours ?

Application: KiCad
Version: (5.99.0-326-g583339268), release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.58.0 GnuTLS/3.5.18 zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3
Platform: Linux 4.15.0-66-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
    Build date: Nov 9 2019 22:00:35
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.22
    Boost: 1.65.1
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.58.0
    Compiler: GCC 7.4.0 with C++ ABI 1011

Build settings:
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=OFF
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=OFF
    KICAD_STDLIB_DEBUG=OFF
    KICAD_STDLIB_LIGHT_DEBUG=OFF
    KICAD_SANITIZE=OFF

[Ian McInerney (imcinerney)]

To get the debug symbols, you have to tell CMake to build a debug version by passing
-DCMAKE_BUILD_TYPE=Debug on the CMake command line.

I am also unable to reproduce a crash by just opening the paths dialog.

[Rene Poeschl (poeschlr)]

The path variables alone don't really tell KiCad where your libraries live. KiCad does not search some (configurated) path for libraries.

The path variables are there to make library tables portable. The library tables that are distributed with KiCad do use path variables. Meaning the default installation does indirectly use these path variables.

Be aware that the library tables are not updated by the installers (they are user files, the installer is not allowed to touch them). Meaning if you have trouble with "wrongly" installed libs then you most likely have an outdated library table. (The installer can not do anything about that -> This requires user action! It would be nice if there is an easy "reset to defaults" option but right now the only way to do this is by deleting your personal lib tables.)

[Franck78 (fbourdonnec)]

looks like this is not solved :
 // report https://bugs.launchpad.net/kicad/+bug/1577786.
kiwai.cpp line 200

I repeat, fresh install, no previous version run on the machine.
Same logged as root or user.

@Rene, I will probably file a bug report about this. Have you ever (re-)installed an antivirus and not wanting the latest&correct definitions with it.....

(gdb) backtrace
#0 0x00007ffff541ce97 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007ffff541e801 in __GI_abort () at abort.c:79
#2 0x00007ffff6030957 in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007ffff6036ab6 in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007ffff6036af1 in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007ffff6036d24 in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00005555556fe5e4 in KIWAY::KiFACE(KIWAY::FACE_T, bool) (this=0x555555c24d40 <Kiway>, aFaceId=KIWAY::FACE_PCB, doLoad=true) at /home/fbc/Documents/kicad/common/kiway.cpp:213
#7 0x0000555555787b88 in COMMON_CONTROL::ConfigurePaths(TOOL_EVENT const&) (this=0x555555ff56a0, aEvent=...) at /home/fbc/Documents/kicad/common/tool/common_control.cpp:52
#8 0x0000555555789d2a in std::__invoke_impl<int, int (COMMON_CONTROL::*&)(TOOL_EVENT const&), COMMON_CONTROL*&, TOOL_EVENT const&>(std::__invoke_memfun_deref, int (COMMON_CONTROL::*&)(TOOL_EVENT const&), COMMON_CONTROL*&, TOOL_EVENT const&) (__f=@0x5555561b8bd0: (int (COMMON_CONTROL::*)(COMMON_CONTROL * const, const TOOL_EVENT &)) 0x555555787b42 <COMMON_CONTROL::ConfigurePaths(TOOL_EVENT const&)>, __t=@0x5555561b8be0: 0x555555ff56a0, __args#0=...)
    at /usr/include/c++/7/bits/invoke.h:73
#9 0x0000555555789c70 in std::__invoke<int (COMMON_CONTROL::*&)(TOOL_EVENT const&), COMMON_CONTROL*&, TOOL_EVENT const&>(int (COMMON_CONTROL::*&)(TOOL_EVENT const&), COMMON_CONTROL*&, TOOL_EVENT const&) (__fn=
    @0x5555561b8bd0: (int (COMMON_CONTROL::*)(COMMON_CONTROL * const, const TOOL_EVENT &)) 0x555555787b42 <COMMON_CONTROL::ConfigurePaths(TOOL_EVENT const&)>, __args#0=@0x5555561b8be0: 0x555555ff56a0, __args#1=...)
    at /usr/include/c++/7/bits/invoke.h:96
#10 0x0000555555789b8a in std::_Bind<int (COMMON_CONTROL::*(COMMON_CONTROL*, std::_Placeholder<1>))(TOOL_EVENT const&)>::__call<int, TOOL_EVENT const&, 0ul, 1ul>(std::tuple<TOOL_EVENT const&>&&, std::_Index_tuple<0ul, 1ul>) (this=0x5555561b8bd0, __args=...) at /usr/include/c++/7/functional:469
#11 0x00005555557899d2 in std::_Bind<int (COMMON_CONTROL::*(COMMON_CONTROL*, std::_Placeholder<1>))(TOOL_EVENT const&)>::operator()<TOOL_EVENT const&, int>(TOOL_EVENT const&) (this=0x5555561b8bd0, __args#0=...)
    at /usr/include/c++/7/functional:551
#12 0x00005555557897b4 in std::_Function_handler<int (TOOL_EVENT const&), std::_Bind<int (COMMON_CONTROL::*(COMMON_CONTROL*, std::_Placeholder<1>))(TOOL_EVENT const&)> >::_M_invoke(std::_Any_data const&, TOOL_EVENT const&) (__functor=..., __args#0=...) at /usr/include/c++/7/bits/std_function.h:302
#13 0x00005555557b4201 in std::function<int (TOOL_EVENT const&)>::operator()(TOOL_EVENT const&) const (this=0x5555560d5500, __args#0=...) at /usr/include/c++/7/bits/std_function.h:706
#14 0x00005555557affe4 in COR...

[Franck78 (fbourdonnec)]

related....

16:14:43: libkicad_3dsg.so.2.0.0: Ne peut ouvrir le fichier d'objet partagé: Aucun fichier ou dossier de ce type
16:14:43: IO_ERROR: Failed to load kiface library "/usr/local/bin/_pcbnew.kiface".

from kiway.cpp : KiFACE() line:213

Pavilion-dvF:/usr/local/bin$ ldd _pcbnew.kiface
 linux-vdso.so.1 (0x00007ffcfc150000)
 libwx_gtk3u_gl-3.0.so.0 => /usr/lib/x86_64-linux-gnu/libwx_gtk3u_gl-3.0.so.0 (0x00007fe847996000)
 libwx_gtk3u_aui-3.0.so.0 => /usr/lib/x86_64-linux-gnu/libwx_gtk3u_aui-3.0.so.0 (0x00007fe847706000)
 libwx_gtk3u_adv-3.0.so.0 => /usr/lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0 (0x00007fe847334000)
 libwx_gtk3u_html-3.0.so.0 => /usr/lib/x86_64-linux-gnu/libwx_gtk3u_html-3.0.so.0 (0x00007fe847061000)
 libwx_gtk3u_core-3.0.so.0 => /usr/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0 (0x00007fe84683e000)
 libwx_baseu_net-3.0.so.0 => /usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0 (0x00007fe8465fa000)
 libwx_baseu-3.0.so.0 => /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 (0x00007fe84616b000)
 libwx_baseu_xml-3.0.so.0 => /usr/lib/x86_64-linux-gnu/libwx_baseu_xml-3.0.so.0 (0x00007fe845f5b000)
 libwx_gtk3u_stc-3.0.so.0 => /usr/lib/x86_64-linux-gnu/libwx_gtk3u_stc-3.0.so.0 (0x00007fe845b1b000)
 libpython2.7.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0 (0x00007fe84559e000)
 librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe845396000)
 libkicad_3dsg.so.2.0.0 => not found

libkicad_3dsg.so not installed ????????????

[Ian McInerney (imcinerney)]

Where are you launching the program from? Is it from the build directory or did you run a make install first?

[Franck78 (fbourdonnec)]

ldconfig fixed thoses two cases....

Question are

-why this single shared lib ??
-why no ldconfig after installing this shared lib ?
-handling of missing shared lib is obviously not fixed

[Nick Østergaard (nickoe)]

So you did't use make install?

If you are not using make install, you are on your own to make sure you are usimg the correct binaries.

[Ian McInerney (imcinerney)]

It is not the job of the build system to run the library configuration utility silently without the user's consent (see: https://cmake.org/pipermail/cmake/2016-June/063715.html for the reason behind this). KiCad installs the libkicad_3dsg.so file to /usr/lib64 on Linux by default, and there have not been any other reports of this breakage, so it seems that something in your system may not be configured correctly.

Does the original crash still occur, or has it disappeared?

[Franck78 (fbourdonnec)]

@Nick, yes I did use 'make install' as root.

@Ian, sorry I don't see a reason behind this (it is only an opinion from someone) and it does not apply anyway. The compilation (cmake stuff) is OK and nothing is installed.

make install puts DSO:

libkicad_3dsg.so in /usr/local/lib
and
libs3d_plugin_{idf,oce,vrml}.so in /usr/local/lib/kicad/plugins/3d

and from the moment you install new shared lib, informing the host is not harmfull and mandatory.

https://unix.stackexchange.com/questions/519163/activate-noawait-ldconfig-trigger-for-runtime-library-package

or
https://lintian.debian.org/tags/package-must-activate-ldconfig-trigger.html

or
https://<email address hidden>/thread/DVBZI2UJRHI5GVMJXIQNLHK4TUFS5ZM2/

"The Packaging Guidelines currently require that packages must call ldconfig if they install or install shared objects:"

The problem they face is when installing a distro, say 1000 packages, it's 1000 calls to ldconfig and perhaps 900 useless. They want to optimize wihtout a package failing to install because of an unloadable command.

Again, Kicad is the exception here by not triggering ldconfig in some way.

[Franck78 (fbourdonnec)]

yes I know, it is not really a rpm nor a deb while inside the build directory.
But the result is there
Broken after install.

Doing it by "rpm -i kicad" or "dpkg -i kicad" or "make install" are equivalent things

[Wayne Stambaugh (stambaughw)]

Sorry bug `dpkg -i` and `rpm -i` are *not* the same as `make install`. They are platform specific packaging tools. Make is a build tool that makes no assumptions about your system configuration. That is a task left to the developer. If the default CMake install paths do not work correctly for the developers system, the developer is responsible for configuring them correctly at config time. I would reject any patch that runs ldconfig from `make install`.

[Franck78 (fbourdonnec)]

What's the deal here ?

Maintaining compatibility with some weirdo Linux platforms? Having Kicad running on some embedded Linux ?
Might not be an exact first priority requirement.

So, all the normal distros running Kicad are glib based.

You don't want to 'ldconfig'. Good. Many other products don't to it either. But they specifically use dlopen to manage their DSO.

You cannot rely on the system and not informing it as part of the install and not manage yourself that stuff (locating/loading dso).

Result is here : a stupid undue segfault. And when this occurs with a new user, you can be sure he is a lost new user. Never forget that you can do nothing with Kicad after a 'make install'
You still have to discover where/why/how add the components/footprints.

The bare minimum than can be done is writing 4 text lines of things to do to finish the make install job.

[Nick Østergaard (nickoe)]

Franck78, you need to add /usr/local/lib to your ld conf if you want to use that path. Otherwise configure cmake with the -DCMAKE_INSTALL_PREFIX=/usr and possibly -DCMAKE_INSTALL_LIBDIR=lib

This is no bug.

[Nick Østergaard (nickoe)]

Running ldconfig is the responsibility of the user (usually a devloper in this case) or a packaing script, but not kicad.

[KiCad Janitor (kicad-janitor)]

KiCad bug tracker has moved to Gitlab. This report is now available here: https://gitlab.com/kicad/code/kicad/-/issues/2585