Black-Hole's Blog

A few days ago we hit a fairly interesting production issue. A Bun service was periodically pegging one CPU core across three pods, for exactly 10 minutes each time, then dropping back on its own. The service itself was fine: requests worked, health checks never failed. The CPU graph just looked awful.

It turned out to be two problems that are each pretty mild on their own, stacked on a specific kernel version and a specific Bun patch release. Writing it down.

It’s been quite a while since I last built Electron on Windows. Yesterday afternoon, I tried building the [email protected] tag, but it failed repeatedly. Strangely, the latest commit built without any issues. I ended up debugging it late into the night.

I tried both PowerShell and Command Prompt, rebuilt the entire source tree from scratch, and even restarted my machine — to no avail.

Reproduction Environment:

• Electron 39.6.0 (tag)
• Windows 10/11
• Tested in both PowerShell and Cmd

My first suspicion was a depot_tools version issue, but @electron/build-tools updates depot_tools automatically before starting the build, so that wasn’t the culprit.

When developing an Electron application, you might encounter crashes. However, for various reasons, the application may not have integrated Sentry or other crash analysis platforms. In such cases, you need to manually check the crash logs to identify the issue.

Since Electron is based on Chromium, the crash-related operations are largely consistent with Chromium.

In the Chromium crash-reports, we can see that crash files are stored in the ~/Library/Application\ Support/Chromium/Crashpad/completed directory. However, since we are using an Electron application and there is no “submission” process, the crash files are kept in the ~/Library/Application\ Support/Chromium/Crashpad/pending directory.

A few days ago, I upgraded from Fedora 39 to Fedora 40. However, after the upgrade, my VirtualBox could not start properly due to a mismatch between the kernel and kernel-header versions.

By using uname -r and dnf list --installed | grep "kernel-headers", I found out the versions are as follows:

• kernel: 6.8.8-300.fc40.x86_64
• kernel-headers: 6.8.3-300.fc40.x86_64

I tried to install the matching version of kernel-headers using sudo dnf install kernel-headers-$(uname -r), but found that there was no corresponding version available.