Fedora

Static analysis updates in GCC 11

Static analysis updates in GCC 11

The GNU logo.
I work at Red Hat on the GNU Compiler Collection (GCC). In GCC 10, I added the new -fanalyzer option, a static analysis pass for identifying various problems at compile-time, rather than at runtime. The initial implementation was aimed at early adopters, who found a few bugs, including a security vulnerability: CVE-2020-1967. Bernd Edlinger, who discovered the issue, had to wade through many false positives accompanying the real issue. Other users also managed to get the analyzer to crash on their code.

I’ve been rewriting the analyzer to address these issues in the next major release, GCC 11. In this article, I describe the steps I’m taking to reduce the number of false positives and make this static analysis tool more robust.

Continue reading “Static analysis updates in GCC 11”

Share
Use vim in a production Red Hat OpenShift container in 6 easy steps

Use vim in a production Red Hat OpenShift container in 6 easy steps

Disclaimer: In most cases, we don’t recommend editing files in a container. However, in rare cases, you might need to reproduce and slightly modify a file in a production container, especially when debugging. (In this case, the vim method I’m using works on Fedora 32 on my laptop and it is the base of my Red Hat OpenShift container image.)

Continue reading Use vim in a production Red Hat OpenShift container in 6 easy steps

Share
Installing Red Hat’s migration toolkit for applications on your laptop

Installing Red Hat’s migration toolkit for applications on your laptop

If you are a developer considering modernizing your Java applications by containerizing or migrating them to a more modern application server, then you are likely aware of Red Hat’s migration toolkit for applications. This article helps you get started with migration toolkit for applications by installing it directly on your laptop. For more about the toolkit, see:

Note: Red Hat’s migration toolkit for applications (formerly Red Hat Application Migration Toolkit) is based on the upstream, open source Windup project. Check out the code and see how it works!

Continue reading “Installing Red Hat’s migration toolkit for applications on your laptop”

Share
Static analysis in GCC 10

Static analysis in GCC 10

I work at Red Hat on GCC, the GNU Compiler Collection. For the next major release of GCC, GCC 10, I’ve been implementing a new -fanalyzer option: A static analysis pass to identify various problems at compile-time, rather than at runtime.

My thinking here is that it’s best to catch problems as early as possible as the code is written, using the compiler the code is written in as part of the compile-edit-debug cycle, rather than having static analysis as an extra tool “on the side” (perhaps proprietary). Hence, it seems worthwhile to have a static analyzer built into the compiler that can see exactly the same code as the compiler sees—because it is the compiler.

Continue reading “Static analysis in GCC 10”

Share
Implicit function declarations: flex’s use of “reallocarray”

Implicit function declarations: flex’s use of “reallocarray”

Several months ago, I took over the maintenance of the flex package in Fedora and decided to kick the tires by rebasing the package in Fedora Rawhide. I downloaded and hashed the latest tarball at the time, flex-2.6.4, tweaked the spec file, and fired up a local build. Unfortunately, it failed with a SIGSEGV at build time:

./stage1flex -o stage1scan.c ./scan.l
make[2]: *** [Makefile:1695: stage1scan.c] Segmentation fault (core dumped)

Some debugging with gdb led me to the conclusion that the segmentation fault was the result of a block of memory returned from the reallocarray function being written to during flex initialization.  In this article, I’ll describe the issue further and explain changes made to address it.

Continue reading “Implicit function declarations: flex’s use of “reallocarray””

Share
A platform interface for the GNU C Library

A platform interface for the GNU C Library

Application developers continue to need newer versions of libraries, including core runtimes like GNU C Library (glibc), for their applications. In this article, I’ll look at some issues related to upgrading glibc in an operating system (OS) distribution, and I also encourage you to read Florian Weimer’s excellent blog post on the topic.

The problem

Deciding between a library rebase or continued backporting of commits involves a complex set of risks and rewards. For some customers and users, it is important not to rebase the library (ensuring the lowest risk of impact by change); but for others, the rebase brings valuable bug fixes (lowest risk of impact from known issues). In other cases, the newer library may perform better, even if the interfaces haven’t changed, because it can take advantage of newer hardware or a newer Linux kernel (performance advantage to first mover).

There is no way to simultaneously satisfy all the requirements of slow-moving versus fast-moving development. The recent work in Fedora Modularity is aimed at solving the root of this problem, but there is a limit to this work. The further down the stack you go, the harder the problem becomes. The potential for breakage further up the stack increases. You can’t always arbitrarily change a component’s installed version without consequences, either at build time or at runtime.

Continue reading “A platform interface for the GNU C Library”

Share