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”
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
For a long time at Red Hat, all executables in RPMs were built with debuginfo enabled. While this practice makes it easier for people in support to investigate issues reported using tools such as GDB and crash, there are other important non-debugging uses for the resulting debuginfo.
Continue reading Debuginfo is not just for debugging programs
Daylight saving time transitions, a zone name change, and the removal of some obsolete files: These are some of the changes that occurred in the Time Zone Database (tzdata) package that provides Red Hat Enterprise Linux (RHEL) and applications with time zone information.
Continue reading 2020 Time Zone Database (tzdata) changes
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”
When upgrading a package or the Fedora release version, I sometimes hit the error:
Continue reading How to clean up the Fedora root folder
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”
In this article, we look at the various ways .NET Core is made available on Red Hat platforms. We start with an overview of the available platforms, and then show how to install .NET Core on each of them.
Continue reading .NET Core on Red Hat platforms
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: *** [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””
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.
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”