Tag / Debugging

  • When debugging kernel problems that aren’t obvious, it’s necessary to understand the history of changes to the source files. For example, a race condition that results in a lockdep warning might have tentacles into multiple code paths. This requires us to examine and understand not only the changes made, but also why they were made. Individual patch commit logs are the best source of the information on why a change was made. So how do we find this information? My goto tool set for such endeavors has been a combination of git gui and git log. Recently I started using cregit. I will go over these options in this blog. git log Running git log on a source file will show all the commits for that file, then you can find the corresponding code change by generating the patch. Using git log can be tedious, but useful for targeted commit […]

    Read More
  • In the upcoming Linux 4.14-rc3 release, work continues to develop the Kselftest TAP13 framework API and convert tests to TAP13. The new tests include Kselftest common RUN_TESTS in lib.mk that have been enhanced to print TAP13 to cover test shell scripts that won’t be able to use the Kselftest TAP13 API; this also covers test programs that aren’t converted yet. Several fixes have been made to existing tests to prevent failure in unsupported cases as part of an ongoing work based on feedback from Kselftest stable release users that don’t want the tests to fail due to unmet dependencies, such as config options being disabled. Additionally, a new watchdog test has been added and much needed cleanups to the existing watchdog tests have been made by Eugeniu Rosca. A New Kselftest Use-Case A notable change in this release is new support for the “make O=dir kselftest” use-case.  Several developers rely on this […]

    Read More
  • February 2, 2017 - Derek Foreman

    A Curious Wayland Bug

    Enlightenment has a slightly unconventional architecture. For many of its internal dialogues (settings, the file manager, etc.) it uses what we call “internal windows.” These are simply regular toolkit windows that use regular rendering back-ends; in the good ol’ days, this meant a connection to the X server which resulted in a render to a standard X window. In this scenario, the compositor gets the result back the same way as all X client windows, and it composites all internal and external windows together. Under Wayland, things get a bit scarier because now the compositor is the display server. Enlightenment makes a Wayland connection to itself; this gives us all manner of game winning capabilities we never had before. For example, let’s say the internal window wants to sleep and wait for a reply from the compositor (such as a released buffer to render the next frame into). We deadlock and fall down […]

    Read More
  • December 1, 2016 - Tom Hacohen

    Improving Debug Code Performance in EFL

    I work on EFL, a cross-platform graphical toolkit written in C. I recently decided to improve one aspect of the experience for developers using the API (otherwise known as users) by making EFL provide more information and stricter sanity checks when developing and debugging applications. A key requirement was ease of use. With these requirements, the solution was obvious, unfortunately obvious solutions don’t always work as well as you expect. The Obvious Solution: an Environment Variable Using an environment variable sounds like a good idea, but it comes with one major, unacceptable flaw: a significant performance impact. Unfortunately, one of the places we wanted to collect debug information was Eo, a hot-path in EFL. Believe it or not, adding a simple check to see if debug-mode is enabled was enough to degrade performance. To illustrate, consider the following code: Note: thanks to Krister Walfridsson for pointing out a mistake in […]

    Read More
  • October 18, 2016 - Thibault Saunier

    Improving Debugging in GStreamer Validate

    Debugging GStreamer is often a hard and time-consuming task; because of this, the community has been working to enhance debugging tools and make it simpler in the gst-devtools official module and its gst-validate component (you can find more information about this in my previous post). Lately, we’ve decided to take a step forward and enhance the GStreamer validate reports for specific and very common GStreamer issues. We started with the classic Not Negotiated Error which basically happens when the elements in the pipeline are not able to agree on a data format (Caps) in which to do the processing. This can happen for many reasons, and until recently, the only way to figure out what went wrong was to read verbose and sometimes hard to read GStreamer debug logs; this is time consuming, particularly for people who are not very familiar with GStreamer. Starting from the next 1.10 release, GstValidate will attempt to explain the precise reason and place in the pipeline […]

    Read More
  • March 11, 2016 - Shuah Khan

    The Linux Kernel Has Bugs! Really!

    A Guide to Finding and Fixing Linux Kernel Bugs “Our new Constitution is now established, and has an appearance that promises permanency; but in this world nothing can be said to be certain, except death and taxes.” said Benjamin Franklin, in a letter to Jean-Baptiste Leroy, 1789. If he were to be around today, he might have added software bugs to the list of unavoidable things. Software and bugs go together, and the Linux Kernel is no exception. Some bugs are easy to find, but some are harder to reproduce and could require several attempts to piece together the right set of conditions to trigger them. While bugs that result in a system crash or hang are easier spot, it is often more challenging to gather the information necessary to debug and fix them. In many cases, Kernel logs can provide insight into these bugs, but when a system crashes or freezes Kernel logs might not get the chance to […]

    Read More
  • May 1, 2015 - Adenilson Cavalcanti and Lars Bergstrom

    Servo Continues Pushing Forward

    Servo is a new prototype web browser layout engine written in Rust that was launched by Mozilla in 2012 with a new architecture to achieve high parallelism on components like layout and painting. It has been progressing at an amazing pace, with over 120 CSS properties currently supported, and work is ongoing to implement the remaining properties. For a full list of the current set of CSS properties with initial support in Servo, check out the Google Docs spreadsheet servo team is using to track development. The current supported properties allow Servo to be mostly operational on static sites like Wikipedia and GitHub, with a surprisingly small code footprint. It has only about 126K lines of Rust code, and the Rust compiler and libraries are about 360K lines. For comparison, in 2014 Blink had about 700K lines of C++ code, and WebKit had around 1.3M lines, including platform specific code. […]

    Read More