The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,706 other followers

Bug squasing: A heisenbug is not your average bug.

Posted by jpluimers on 2016/03/15

I took the liberty to make an English translation of this very interesting German story about squasing an Heisenbug from Kristian KöhntoppHeisenbugsquashing bei +SysEleven: Sechs Monate Kernels crashen, aber jetzt isser tot….

Don’t forget to read (translated) comments in the original thread. Very interesting read!

I agree it’s in the Heisenbug category given “Time can also be a factor in heisenbugs, particularly with multi-threaded applications.”.

Anyway, the translation and original:


Squasing Heisenbugs at +SysEleven: After six months of kernel crashes, the bug is now dead or “What are these guys using this beta for?”

Our OpenStack cluster is running underneath the distributed filesystem. The objective of this software, roughly speaking, is to take the hard drives in each computer in the cluster then to transform all these disks into a large redundant file system that is then available for the cluster. All data is stored multiple times, so no data loss can be caused by the failure of an individual computer.

The so constructed file system is then made available in Linux clients using made ​​FUSE. Grosso modo, this works works wonderfully.

However, when we wanted to update our clients to Linux kernel version 4.1 or later, the system frequently collapsed after a brief operation with a Panic message.

So we submitted a bug report in October 2015:

after which we worked together with Quobyte and Canonical to chase this error down.

This has proven to be more complicated than initially thought: the error would appear eventually quite reliably under load and after waiting, it was not possible to associate the error with one particular event.  Instead, it was necessary to generate a load from a set of test machines and then wait for a while, until one of the test machines, the kernel gives up the ghost.  If you do that often enough then after several weeks of troubleshooting a pattern emerges based on which one can guess what the actual problem is.

In fact, it took from October 2015 until early March 2016 before first suspicions were substantiated so far that +Robert Döbbelin could create a patch for it.

Looking at the code, one understands why the error was too hard to find – a race condition, so an error that only occurs when multiple events happen that simultaneously want to change the same variables. A classic

The full fix of Seth Forshee is at

It has become a bit more complicated, but is now ready for incorporation into the kernel, which paves the path for a kernel upgrade and related performance gains.


Heisenbugsquashing bei +SysEleven: Sechs Monate Kernels crashen, aber jetzt isser tot!

oder “Was machen die da eigentlich mit dieser Beta?”

Unser Openstack Cluster läuft ja unten drunter mit dem verteilten Dateisystem. Die Aufgabe dieser Software ist, grob gesagt, die Festplatten in jedem Rechner des Clusters zu nehmen und aus allen diesen Platten ein großes Dateisystem zu bauen, das dann für den Cluster zur Verfügung steht. Dabei werden alle Daten mehrfach gespeichert, sodaß durch den Ausfall eines einzelnen Rechners kein Datenverlust entstehen kann.

Das so gebaute Dateisystem wird in Linux-Clients mit Hilfe  von FUSE nutzbar gemacht und im Großen und Ganzen funktioniert das ganz wunderbar.

Als wir jedoch unsere Clients auf die Linux Kernelversion 4.1 oder höher aktualisieren wollten, stürzten die Systeme nach kurzem Betrieb häufig mit einer Panic-Meldung ab.

Einen Bug Report dazu haben wir im Oktober 2015 eingeworfen:

und seitdem zusammen mit Quobyte und Canonical dem Fehler hinterher gejagt.

Das hat sich als aufwendiger herausgestellt als zunächst gedacht, denn obwohl sich der Fehler recht zuverlässig nach einiger Zeit unter Last provozieren ließ, war er nicht mit genau einem Ereignis zu assoziieren. Stattdessen mußte man auf einer Gruppe von Testmaschinen Last erzeugen und dann eine Weile warten, bis auf einer der getesteten Maschine der Kernel den Geist aufgibt. Wenn man das nur oft genug macht ergibt sich dann nach einigen Wochen Fehlersuche ein Muster auf dessen Grundlage man vermuten kann, was das Problem ist.

Tatsächlich hat es dann von Oktober 2015 bis Anfang März 2016 gedauert, bis sich erste Verdachtsmomente so weit erhärten ließen, die sich von +Robert Döbbelin in so etwas wie einen Patch gießen ließen.

Wenn man sich den Code ansieht, versteht man, wieso der Fehler zu schwer zu finden war – eine Race-Condition, also ein Fehler, der nur dann auftritt, wenn mehrere Ereignisse zufälligerweise zeitgleich dieselben Variablen verändern wollen. Der klassische

Der vollständige Fix von Seth Forshee ist in

Er ist ein bischen komplizierter geworden, steht jetzt aber zum Einbau in den Kernel bereit, und damit ist der Weg für das Kernelupgrade – und die damit zusammenhängenden Performancegewinne – frei.


Images from the original post:

PS: of course “gives up the ghost” was intentionally translated as such.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: