A passionate openSUSE user
RSS icon Home icon
  • Debug a crash after it happened – without knowing about it upfront

    Posted on April 8th, 2014 Dominique Leuenberger No comments

    Do you happen to find yourself in the situation that you have a program crash every now and then, but whenever this happens to you, you did not start the app in gdb?

    Then I know that feeling; this guide will help you configure your test system to create a coredump whenever an app crashes, so if needed, you can use those at any later time to still create a backtrace. There are obviously some limitations, like stepping through and anything else funny you could do while debugging a running app. But it still does give you a good entry point.

    NOTE: I do not advise to set this up on shared machines or critical machines. A coredump can contain sensitive data (memory extracts), which you would not want to be shared around.

    With that cleared, it’s as simple as a few configuration steps:

    Create any directory where you want to keep your coredumps. I use /cores
    mkdir -m 777 /cores
    This creates a world readable and writable directory

    Configure your system to know WHERE to store the coredumps and how to name them. Create a file /etc/sysctl.d/99-coredump.conf, with the following content:
    # I want to have core dumps in a world writable directory

    kernel.core_pattern = /cores/%e-%t-%u.core
    The pattern results in a filename /cores/NameOfBinary-TimeStamp-UserID.core; this helps yourself to identify the more recent crashes.

    Modify the file /etc/security/limits.conf and add the line
    * soft core unlimited
    instructing the system to actually write coredumps for you.

    Reboot your system and go ahead, make your apps crash. you will see files appear in /cores, if all is setup right.

    You can at any time later start gdb with two parameters, first one pointing to the binary to debug, 2nd parameter to the corefile. Then normal gbd usage applies (if you miss debuginfo packages, you can even still install them at this time: the coredump remains valid). The usage of gdb goes beyond the scope of this article.

  • gobject-introspection based dependencies – take 3

    Posted on February 13th, 2014 Dominique Leuenberger No comments

    For a long time, openSUSE has been parsing JavaScript and python script during the packaging process to identifty gobject-introspection based dependencies and translated those into rpm dependencies (see my two previous posts and ).

    The GNOME Developers (upstream) were busy improving performance of many of the tools (like gnome-shell) by avoiding the clutter of many small javascript files. This was done by embedding the javascript files as GResources into an ELF binary. Pretty neat, but the gobject-scanner which openSUSE employed no longer detected the dependencies and the ‘traditional’ ELF dependency scanner also does now know what this is about.

    The solution: fired up vi, hacked a few lines of shell code together (which, in fact is how the original scanner is mostly implemented, plus a glib based tool). The scanner (gi-find-deps.sh) now not only checks javascript and python files, but also tries to inspect ELF binaries, extracting the GResources if any found and then scanning those resources for eventual dependencies.

    The time penalty is acceptable, considering that building is done ‘once’ for all the users and the fact that we get more reliable dependencies is certainly worthy the few extra cycles.

    The fixed scanner is on it’s way from DEVEL to GNOME:Next -> GNOME:Factory -> openSUSE:Factory and will finally be in used in the next openSUSE version (13.2).

    If you happen to find issues with the new scanner, please drop me a note so that this can be corrected.