error message when exiting klayout

edited April 2018 in General
Hi

when I exit klayout, I always got the following error message (does not appear to be layout dependent). I used the pre-compiled klayout binary, downloaded from this website.

ERROR: Signal number: 11
Address: 0x0
Program Version: KLayout 0.25.1 (2018-02-24 re7e0f11)

Backtrace:
/usr/lib64/klayout/libklayout_lay.so.0 +0x291970 std:GDN_Rb_tree<std::string, std::pair<std::string const, std::pair<lay::SaltModel::Severity, std::string> >, std:GDN_Select1st<std::pair<std::string const, std::pair<lay::SaltModel::Severity, std::string> > >, std::less<std::string>, std::allocator<std::pair<std::string const, std::pair<lay::SaltModel::Severity, std::string> > > >:GDN_M_insert_unique(std::pair<std::string const, std::pair<lay::SaltModel::Severity, std::string> > const&) [??:?]
/lib64/libpthread.so.0 +0xf5e0 __restore_rt [sigaction.c:?]

My system is CentOS 7 and "uname -a" output is as follows

3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

I never saw any crash while using klayout, just always got this error message when close the viewer

Thanks
enuinc

Comments

  • edited November -1

    Hi enuinc,

    I'm sorry, I can't easily reproduce the issue. I tried with a virgin CentOS 7 instance and did not see that issue. At least not with 0.25.2 which is the latest version.

    Maybe it's related to some packages or macros. Could you try to start with a clean configuration? Like

    KLAYOUT_HOME=~/doesnotexist klayout
    

    This should switch KLayout's root configuration directory to something that is non-existing and forces it to start with a clean configuration.

    Kind regards,

    Matthias

  • edited November -1
    I tried the suggestion (setenv KLAYOUT_HOME ~/doesnotexist and use latest build binary) and still get the following

    ERROR: Signal number: 11
    Address: 0x33ba400
    Program Version: KLayout 0.25.2 (2018-03-20 r21e2af2)

    Backtrace:
    /usr/lib64/klayout/libklayout_lay.so.0 +0x291f30 std::_Rb_tree<std::string, std::pair<std::string const, std::pair<lay::SaltModel::Severity, std::string> >, std::_Select1st<std::pair<std::string const, std::pair<lay::SaltModel::Severity, std::string> > >, std::less<std::string>, std::allocator<std::pair<std::string const, std::pair<lay::SaltModel::Severity, std::string> > > >::_M_insert_unique(std::pair<std::string const, std::pair<lay::SaltModel::Severity, std::string> > const&) [??:?]
    /lib64/libpthread.so.0 +0xf5e0 __restore_rt [sigaction.c:?]
    /lib64/libpthread.so.0 +0xffff80d57a7a5400 ?? [??:0]

    It does not affect my using the klayout viewer. I will compile myself the code and see if the problem goes away

    Thanks
    enuinc
  • edited November -1

    Hi enuinc,

    I'm running CentOS 7 in a Docker instance. Maybe that makes a difference (although I'm fairly sure this should not be an issue here). libc comes to mind. But I'm not aware of incompatibilities in our domain.

    The backtrace doesn't give me a clue - apparently the stack is pretty messed up. Building yourself is definitely an option. I'd bet the problem is gone then, but building is somewhat tedious. That's why I provide an RPM.

    Kind regards,

    Matthias

  • edited November -1
    Hi Matthias

    I have recompiled the klayout (yes it did take a while:-)). I used the following command to build

    build.sh -noruby -python /usr/bin/python

    I still get the error message, but a slightly different one now

    ERROR: Signal number: 11
    Address: 0x26a4650
    Program Version: KLayout 0.25.2 (2018-04-08 rLatestSourcePackage)

    Backtrace:
    ./libklayout_lay.so.0 +0x291f20 lay::signal_handler(int, siginfo_t*, void*) [laySignalHandler.cc:284]
    /lib64/libpthread.so.0 +0xf5e0 __restore_rt [sigaction.c:?]
    /lib64/libpthread.so.0 +0xffff80fe71f72650 ?? [??:0]

    Not sure if it helps. I am running in a VM machine and I manually installed the OS myself (didn't use docker or anything like that)

    anyway, if this does not help you to figure out the issue, can you suggest how to run a debugger so that I can figure out what cause the error message and then pass that info to you?

    Thanks for your time
    enuinc
  • edited April 2018

    Thanks as well ... but this is really annoying. The stack trace still just tells the location I already knew - but in order to be useful it needs to continue. And since it stops that means the stack is corrupted :-(

    I'm also afraid that gdb won't print much more information in that case. So debugging isn't an option either.

    Good news is that my build shows the same which means that a Docker build is not worse than a native one.

    Just a few things may be worth checking:

    • Are you using your own locale maybe? Somthing different from en_US.UTF-8?

    • Will it also crash if run in batch mode or without UI? I.e. - will any of these crash:

      • "klayout -h"
      • "klayout -b"
      • "klayout -z"

    Matthias

  • edited November -1
    Matthias

    None of the three commands will cause the error message.

    I don't know what locale I used, so it must be the default one

    Thanks
    enuinc
  • edited April 2018

    "locale" is the language setting of the system. I assume the default is OK then.

    The commands narrow that down a little, but not much.

    A better option than a debugger is "valgrind" (a memory checker). I think you can install it with "yum install valgrind".

    Run KLayout with

    valgrind klayout .. >valgrind.log 2>&1
    

    Valgrind makes the program run much slower, but it will report potential memory corruption issues. If the program happens to crash then, the log should contain some hints about what goes wrong.

    The output can become pretty huge, but if you send the file to via (mail address on the contact page) I can offer to take a look.

    Thanks and best regards,

    Matthias

  • edited November -1
    Matthias

    I will run this through valgrind and send you the log file

    Thanks
    enuinc
  • Thanks for sending the valgrind log.

    I was able to track down the issue - apparently KLayout deletes a QMenu which belongs to the multi input context plugin.

    I can trigger the bug on my installation when adding this line to ~/.config/Trolltech.conf in the [Qt] section:

    DefaultInputMethod=imsw-multi
    

    By using

    DefaultInputMethod=ibus
    

    I don't a segfault.

    This workaround may not always work: Qt skips this config entry if there are multiple input context plugins installed (in KLayout's macro editor: if RBA::QInputContextFactory::keys.size > 2).

    Since I know the cause I can fix this issue. It will go into the next minor release.

    Thanks,

    Matthias

  • I have created GitHub #203 to track this issue.

Sign In or Register to comment.