ERROR: Signal number: 11 Address: 0x0 Program Version: KLayout 0.28.12 (2023-09-12 r8212b7c)

gkamendje

I sometime get the following error message while closing some windows or when leaving Klayout.
ERROR: Signal number: 11
Address: 0x0
Program Version: KLayout 0.28.12 (2023-09-12 r8212b7c)

Backtrace:
/usr/lib64/klayout/libklayout_lay.so.0 +0x291ebe lay::enable_signal_handler_gui(bool) [??:?]
/lib64/libpthread.so.0 +0xf630 __restore_rt [sigaction.c:?]

Crash log written to ./klayout_crash.logmake

I am running on CentOS
LSB Version: :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID: CentOS
Description: CentOS Linux release 7.9.2009 (Core)
Release: 7.9.2009
Codename: Core

Matthias

Please send the "klayout_crash.log" file.

gkamendje

The log file is almost empty below is the only content.

Backtrace:
/usr/lib64/klayout/libklayout_lay.so.0 +0x291ebe lay::enable_signal_handler_gui(bool) [??:?]
/lib64/libpthread.so.0 +0xf630 __restore_rt [sigaction.c:?]

Matthias

That is weird. There should be some stack trace.

I had a few crashes myself on Ubuntu 22 when shutting down KLayout. They were usually happening when I left the window open for a long time and I was not able to reproduce them. So far, I did not see side effects, but I'll keep looking. Maybe fixing my issues will also fix them on CentOS7.

Matthias

Theo

Hi
I have the same issue on CentOS7.

It happens consistently when I either add one shape or set the context to another (sub) cell.
I close klayout by using the window menu (X) or File->exit

When I open a layout and close it right away, I do not see a crash.
Currently using 0.28.17, which seem to have this issue.
I also tried 0.28.10 which also has this issue
I also tried 0.27.12 which does not have this issue

klayout_crash.log content:

Signal number: 11
Address: 0x1dee2630
Program Version: KLayout 0.28.17 (2024-02-16 r888252e)

Backtrace:
/libs/soc/apps/klayout/klayout-0.28.17/OS7/lib64/klayout/libklayout_lay.so.0 +0x296f9e lay::enable_signal_handler_gui(bool) [??:?]
/lib64/libpthread.so.0 +0xf630 __restore_rt [sigaction.c:?]
/lib64/libpthread.so.0 +0xffff80ae5593f630 ?? [??:0]

Matthias

You mean, just adding a shape on the top level of the layout crashes the application?

So like:

• Open KLayout in editor mode
• New layout with one layer
• Select the layer
• Choose Box mode
• Click two times to make the box
• Exit KLayout -> crash

?

Matthias

Matthias

I just tried the 0.28.17 RPM from the download page on a CentOS 7 docker container.

I was not able to reproduce the issue with a simple editing session like the one sketched.

Matthias

Matthias

@Theo I can't say how your version was built. I assume that it is not the one from the public server. You can check what libraries the application pulls and whether these are the ones you have built for.

You can set LD_DEBUG=files to get a log of the shared objects loaded. You should not see libs being loaded from outside the installation or from Qt versions not being the one you built against.

You can also try to set KLAYOUT_HOME to some new folder to start with a fresh configuration. Maybe that makes a difference. In that case the problem may be caused by something else like a package you have installed.

Matthias

Theo

Hi Matthias
Yes as you describe also makes the exit crash. I did the edit on top of an existing gds, so that gives the same result.
I unset KLAYOUT_PATH, and created a new layout. Defined one layer and added a shape. Still the crash at exit.
I use the rpm download for centos7 from the klayout website. I do not install the rpm (no rights to do so...) but unpack it with rpm2cpio. In this way I can place it to a different location with CAD user rights and distribute it to all server locations worldwide in our company. LD_LIBRARY_PATH is set to the new location.
Our systems do have some special restrictions like no execute from /tmp

With LD_DEBUG is see this fatal error come by more than once:
27950: /libs/soc/apps/klayout/klayout-0.28.17/OS7/lib64/klayout/db_plugins/libmag.so: error: symbol lookup error: undefined symbol: dbp_init (fatal)

The local system has glibc-2.17-326.el7_9.x86_64 installed. (That is the package for /lib64/libpthread.so.0)

Matthias

Hi @Theo,

I am not sure if you can simply move the installation somewhere else. The RPM is built with RPATH and setting LD_LIBRARY_PATH may not have the desired effect of redirecting to the right libs.

I have never used a prepackage version in a different place. At least there is a good chance that Qt libraries are not matching or Ruby or Python isn't. The fatal dynamic linker error is a strong indicator something is wrong.

Do you have a chance to build from sources? Dependencies are not many - but you will need a C++ toolchain, a compatible Qt development environment and development libs for Ruby and Python. libgit2 development libs are handy too. If you build from sources, you make sure you have compiled against your own libraries.

Matthias

Theo

I cannot compile myself, but I can link to a different version of the packages if I would know which version I would need.

Matthias

You can get the dependencies with

rpm -qp klayout-xyz.rpm --requires

There is a flatpak version of KLayout: https://github.com/KLayout/klayout/issues/125. I have not tried myself, but may you are able to use that? It should avoid the dependencies issue. I wanted to try appimage myself as this comes without sandbox mode and looks simple enough for me to understand, but I did not have time to do so yet.

Matthias

Theo

$ rpm -qp klayout-0.28.17-0.x86_64.rpm --requires
warning: klayout-0.28.17-0.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 6839b9fe: NOKEY
ruby >= 2.0.0
python3 >= 3.6.0
qt-x11 >= 4.8.5
libgit2 >= 0.26.8
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadIsXz) <= 5.2-1

I checked and all rpm's are newer:
ruby-2.0.0.648-39.el7_9.x86_64
python3-3.6.8-18.el7.x86_64
qt-x11-4.8.7-9.el7_9.x86_64

Missing is libgit2 which I tried to workaround. I'll have IT install the package to see if that makes a difference. I also tried version klayout-0.29.0-0.x86_64.rpm and it has the same issue.

Theo

Packages have been locally installed but still the same result. I checked a bit more when it crashes on exit.
If I open an existing layout and do any of the following it crashes on exit:

• select the top cell under cells
• select any layer or layer group under layers
• select help->help assistant
• add a shape (but basically I have to do more than one thing, select a layer)

This list is not exhaustive, it's just what I tried.

It's extremely unlikely to not make it crash. For now I reverted back to 0.27.12 which is of course a bit of a pity.

StefanThiede

Considering how easy it is to compile klayout yourself, try that route.
You’ll also be able to run klayout in a debugger in case you still have coredumps.

Matthias

@Theo,

I tried a VirtualBox instance with CentOS 7 and the 0.29 version. Different combinations - RPM, unpacked RPM, self-built ... all appear to be working fine.

I also scanned with Valgrind and apart from the usual noise from Python and Ruby there is nothing obviously wrong.

It really does not make a lot of sense to discuss an unknown configuration. Your IT guys should have a way to build software and after all, that is safer to use external binaries (although I consider myself trustworthy).

Matthias

Theo

The package (+dependencies) has now been installed on a local machine and that shows exactly the same issue. I understand compiling is not difficult, it's just not something I am allowed to do due to the missing devel packages. It makes me believe that it's related to some of the security measures our company takes.

Matthias

So you mean you installed KLayout on some CentOS 7 on some local machine, simply from the RPM and it will crash on exit?

I mean that is exactly what I did, but with VirtualBox and starting with a plain CentOS 7 installation with Gnome. I don't see a crash. I can also do the same with CentOS 7 inside a Docker container and it also does not crash.

Matthias

Theo

Correct that is exactly what I did (well one of the IT guys installed the packages for me on my workstation). We will do another experiment with temporarily disabling some security measures (we trust you Matthias )
Will keep you posted.

Theo

We also disabled all security measures that could potentially block access but issue remains. So latest rpm installed on CentOS7 installation. Home drive is on nfs. If there is anything I can do to debug, let me know.

Matthias

I think security features are not responsible here.

Basically, when you run a binary, it is always built against a certain version of a library. When KLayout calls functions from another library, it will do so under the assumption that these functions behave like the version it was built against, that the compiler uses the same call details (ABI), that data structures are exactly the ones expected, memory layout of objects is expected and such. That is the contract between KLayout and the system libraries. Some libraries are robust, some are not. Some libraries pull in other libraries which creates indirect dependencies. In the context of a Linux distribution, there is a certain guarantee that all libraries are consistent and form a package that is (in most cases) backward compatible. If you deviate from a distribution by patching or modifying it, the effects can be unpredictable.

The crash you describe is very fundamental, not just a glitch. That indicates such a fundamental issue. Unfortunately that is rather little one can do to debug that as that is even outside the scope of a debugger.

A safe deployment in an enterprise environment in my experience is possible only by using the same compiler and runtime libraries for KLayout, Ruby, Python and Qt. This will make sure all components use the same ABI and library interfaces.

Matthias