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…

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.…

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…

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.

Locating Local Crash Logs

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…

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.

How Podman talks to containers

How to build and debug Electron source

Dynamically modifying an already-encoded pb message

Notes on downloading and building Chromium on macOS 10.15

The idea behind server-side recording, and some pitfalls I hit

Starting with macOS 10.14, tighter privacy rules can make Electron apps crash when they use the camera or microphone

Common web attacks and how they work (XSS, CSRF, SSRF, JSON hijacking), plus Docker labs so you can try them

Flexible scheduling of a k8s cluster based on task volume, to save resources

Step-by-step walkthrough of why it prints banana

Integrating the libfdk_aac encoder into FFmpeg, and using a free gitlab-runner to automatically statically compile FFmpeg

Reading the source to understand how GitLab Runner captures jobs

Decide whether to ship by checking the current time