Development

The glibc s390 ABI break

The GNU C library (glibc) project has long lived up to a reputation for conservatism; glibc developers know that an ill-chosen change can create a great deal of pain downstream, so they proceed with caution. Even so, mistakes can happen. A recent slip-up involving the s390 architecture makes it clear how one of those mistakes can cascade into a significant mess that is hard to clean up afterward.

The setjmp() and longjmp() functions have been part of the standard C library since something close to the beginning. They can be used to perform stack unwinding — a sort of "long return" from a function that skips over any number of intervening function calls. Both of these functions take an opaque jmp_buf data structure as an argument. The caller provides the buffer to setjmp(), which fills it with the information needed to make another return to the location of that call. A later call to longjmp() with that buffer will then cause setjmp() to appear to have returned a second time.

Back in April, developers from IBM committed a patch that changed the size of the jmp_buf structure on the s390 architecture; this change, which subsequently became part of the 2.19 release, was apparently needed to enable better hardware support for setjmp() and longjmp(). Since jmp_buf is a type that is visible to applications, this was a clear ABI change, with all of the possible problems that can go with it. For example, newer glibc releases expect the larger jmp_buf size, but they may be linked (at run time) against applications that have not been rebuilt and, thus, are still working with the older version of jmp_buf.

This possibility was taken into account, though. Symbol versioning was used to provide compatible versions of setjmp() and longjmp() for these older applications. So, in theory, things should Just Work without additional problems. This particular theory did not last long after its encounter with the real world, though.

The problem is that jmp_buf structures are often embedded into other structures, so a change in the size of that structure will change the containing structures too. To find victims, one need not even look outside of glibc; it turns out that glibc's POSIX threads (pthreads) implementation embeds a jmp_buf structure into its own __pthread_unwind_buf_t structure which, in turn, is visible to applications. So, as a result, a number of pthreads functions need to become versioned as well.

Versioning does not work, though, for problems that pop up outside of glibc. Consider, for example, the Perl interpreter, which embeds a jmp_buf in its main "this is a running Perl instance" structure. That has caused various Perl modules to fail (example) and can only really be fixed by rebuilding the entire Perl environment. The PNG image format library (libpng) also has an embedded jmp_buf — in a structure that is used by all PNG-using applications.

Debian's developers, who were trying to clean up this mess, considered rebuilding all of Perl and then, perhaps, all (500 or so) packages depending on the PNG library. But, by this point, it became clear that the ripples from this change spread widely indeed and that playing whack-a-mole may never get all of them fixed. So the Debian developers have figured that the course they may have to consider is to "do like Red Hat, ie just rebuild everything and warn the users their system might break during upgrade." Needless to say, this approach lacks appeal, especially in the Debian world, where mass rebuilds are a rare event.

Even then, of course, there is the problem of end-user applications. Distributors cannot rebuild those; even worse, the user may not be able to either. So some things might just be broken.

One might be thinking that there is a mechanism in place for this kind of incompatible ABI change. Shared libraries have a shared-object name ("soname") built into them; applications linked against those libraries also contain that name. For glibc on your editor's system, for example, the soname is "libc.so.6". The runtime linker will not link an application against a shared object if the sonames do not match. In this way, the system can disallow running against a library that will not work. It also enables, in theory, the parallel installation of multiple versions of the library; older applications would continue to use the older library, while newly built binaries would use the current version.

So the glibc project could consider making a point release with a different soname (libc.so.6.1, say); distributors could then install the result alongside an older version of the library and, in theory, things should work. Except that glibc developer Carlos O'Donell tried it and concluded that:

It also turns out to be painful to bootstrap a system with a new, ABI-incompatible version of the C library. So it seems that the soname change will not happen and that, on s390, a lot of rebuilding is going to have to go on. It will also become impossible to move affected applications between systems with pre- and post-change libraries. Not fun, but, as David Miller put it:

That leads to the obvious question: what can be done to avoid this kind of problem in the future? Carlos plans to put together a policy on how to manage ABI changes, with "don't break ABI ever" as the first item. There has been talk of improving the testing tools in an attempt to catch this kind of ABI break in the future.

In the end, though, nothing can replace a high level of care on the part of the developers involved. Glibc developers have always shown that care, which is why stories like this one are rare. In the aftermath of this mistake, one can assume that they will be doubly careful in the future. That, along with some testing support, should help to ensure that upcoming glibc releases are free of this kind of issue.

Comments (12 posted)

Quotes of the week

— Kathy Sierra

— Daniel Silverstone

— Matt Mackall

Comments (14 posted)

KDE Plasma 5.0

KDE has announced the release of Plasma 5.0. "Plasma 5.0 introduces a new major version of KDE's workspace offering. The new Breeze artwork concept introduces cleaner visuals and improved readability. Central work-flows have been streamlined, while well-known overarching interaction patterns are left intact. Plasma 5.0 improves support for high-DPI displays and ships a converged shell, able to switch between user experiences for different target devices. Changes under the hood include the migration to a new, fully hardware-accelerated graphics stack centered around an OpenGL(ES) scenegraph. Plasma is built using Qt 5 and Frameworks 5."

Comments (23 posted)

GNU CSSC 1.4.0 available

Version 1.4.0 of the GNU "Compatibly Stupid Source Control" (CSSC) revision-control suite is now available. This stable release makes some changes to the way headers are produced by sccsdiff, alters the output ordering in sccs unedit to match Solaris, and changes the tar archive format used. "Up to now we have used the v7 Unix tar format, but this does not cope correctly with filenames longer than 99 characters, and we now have one of those. We now use the the ustar format defined by POSIX 1003.1-1988. If you need to unpack a CSSC distrubition with a version of tar which only deals with the v7 format, unpack the distribution somewhere else, rename or delete the long files (they are not essential to the build process) and re-pack it. This new tar format will likely also be used for all future releases."

Full Story (comments: none)

Announcing Gitorious 3.1

The Gitorious code-hosting service has announced the release of version 3.1 of the AGPL-licensed software platform behind the site. Changes include an administrative interface for managing SSH keys, improvements to the commenting system, and "super groups": "One of the requested features was ability to automatically grant access to all of the repositories for all of the users in Gitorious installation. We’re happy to introduce this feature in the form of the “super group”. Super group is a special system group that contains all of the users, and it’s added to all of the projects, both existing and new ones."

Comments (none posted)

AppStream 0.7 available

At his blog, Matthias Klumpp announces the availability of version 0.7 of the AppStream specification and library. Notably, this revision introduces and API/ABI break from version 0.6, so downstream users should proceed with caution. New features include an addon component type that indicates a package is a plugin for use with another package (such as a Firefox extension) and tags for developer names and contact addresses. The library has also changed licensed, from LGPL3+ to LGPL2.1+.

Comments (none posted)

State of Rust 0.11.0

The Rust 'n Stuffs blog is running an article looking back on the past six months of Rust development, including both the changes in the Rust community and those in the project proper. The changes include moving into a separate "organization" on GitHub (rather than being a sub-project of Mozilla), a new discussion forum, an RFC process, and a public of meeting minutes. In addition, there is an official nightly channel, a plugin system for the compiler, and many, many other changes since the last "State of Rust" update.

Comments (none posted)

Development newsletters from the past week

• What's cooking in git.git (July 14)
• What's cooking in git.git (July 16)
• GNU Toolchain Update (July 14)
• LLVM Weekly (July 14)
• OCaml Weekly News (July 15)
• OpenStack Community Weekly Newsletter (July 11)
• Perl Weekly (July 14)
• PostgreSQL Weekly News (July 13)
• Python Weekly (July 10)
• Ruby Weekly (July 10)
• Tor Weekly News (July 16)
• Wikimedia Tech News (July 14)

Comments (none posted)

Day: Sandboxed applications for GNOME

In the first of a two-part series, GNOME contributor Allan Day looks at sandboxed applications for the GNOME desktop. In this installment, he looks at the benefits of application sandboxes from a couple of different angles. "Security and privacy, I think, are core beliefs for Free Software. Users should be able to trust us to have their interests at heart, and should be able to have more faith in our products than proprietary alternatives. Ironically, though, the Free Software desktop world hasn’t done a great job at security. It is actually pretty scary what a malicious desktop application could do if it wants to. We rely on transparency and good faith to ensure that applications do not infringe on user privacy, rather than robust technical architecture."

Comments (25 posted)

Mozilla: Improving JPEG Image Encoding

The Mozilla Blog is running a piece written by CTO Andreas Gal describing Mozilla's recent work to improve the quality of JPEG compression without sacrificing quality. "We published a study last year which compares JPEG with a number of more recent image formats, including WebP. Since then, we have expanded and updated that study. We did not find that WebP or any other royalty-free format we tested offers sufficient improvements over JPEG to justify the high maintenance cost of adding a new image format to the Web." The enhanced encoder (called "mozjpeg"), Gal said, "reduces the size of both baseline and progressive JPEGs by 5% on average, with many images showing significantly larger reductions." Even more detail is available in a Mozilla Research blog post by developer Josh Aas.

Comments (2 posted)