Dominique a.k.a. DimStar (Dim*)

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 1 comment

    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.

  • GNOME 3.12.0 for openSUSE 13.1 ? Maybe…

    Posted on April 6th, 2014 Dominique Leuenberger 3 comments

    Hi there!

    As you are reading this, I guess you have an interest in openSUSE and GNOME; and you are already fully aware of GNOME 3.12 being released. Also, you do not want to wait for the next version of openSUSE 13.2 to be made available (will anyway only be in November, presumably with GNOME 3.14).

    So, how can YOU get GNOME 3.12 NOW on your openSUSE 13.1 system?
    The answer is simple: there IS already a repository available, but it is ABSOLUTELY not meant for the one that could not potentially recover from a bad repository state.

    The repository in question is called ‘home:dimstar:broken’
    zypper ar obs://home:dimstar:broken/openSUSE_13.1 GNOME-3.12
    zypper dup –from GNOME-3.12

    BUT, as the name indicates, it CAN be broken. A group of people did test this repository already and we concluded it ‘working on our machines'; but then, we only have a handful of machines.

    So, if you ARE interested in helping, testing and you are NOT afraid of having to revert from a potentially broken state, please feel free to add the repository, ‘DUP’ to it and enjoy.

    Any breakage notices? Please tell us in #opensuse-gnome on irc.freenode.net; best to hant around there with us and engage; we might have a bunch of question which you would be the only one to answer.

    So? What are you waiting for? GO GET IT!

    If you’re not as brave to add a repository that has ‘broken’ in the name (the name is intentional, for exactly that reason), then please stay tuned; depending on the feedbacks we receive, the repository will be fixed up and once considered stable be moved into the GNOME:STABLE namespace; at which time you can safely get it as well.

    Cheers! Happy testing.