[Linux] Audacity hangs at startup under zh_CN.UTF-8 locale

Description

Audacity hangs during startup on Ubuntu 24.04 with the Kubuntu desktop
settings under a Chinese locale.

The process remains alive and consumes approximately 100% of one CPU core.
Only the startup/placeholder windows are created; the main window never
appears.

This reproduces with a clean Audacity configuration in both the Ubuntu
noble-backports package and the official Audacity 3.7.8 x64-22.04 AppImage.

Steps to reproduce

Use Kubuntu 24.04, or Ubuntu 24.04 with kubuntu-settings-desktop
installed and /etc/fonts/conf.d/56-kubuntu-noto.conf enabled.
Set the system locale to zh_CN.UTF-8.
Launch either:
- Ubuntu noble-backports 3.7.3+dfsg-1~bpo24.04.1; or
- official audacity-linux-3.7.8-x64-22.04.AppImage.
Observe that the process stays at approximately 100% CPU indefinitely and
the main window does not appear.

For example, the Ubuntu package reproduces with isolated configuration and
temporary directories:

cfg=$(mktemp -d)
tmp=$(mktemp -d)

env -u LC_ALL -u LC_CTYPE \
    LANG=zh_CN.UTF-8 \
    LANGUAGE=zh_CN:en_US \
    XDG_CONFIG_HOME="$cfg" \
    TMPDIR="$tmp" \
    GDK_BACKEND=x11 \
    /usr/bin/audacity

Expected behavior

Audacity should open normally with the system Chinese locale.

Actual behavior

Audacity remains stuck during startup, the main window is never shown, and
the process continuously consumes one CPU core.

Runtime investigation

Build	Locale condition	CPU after 8 seconds	Main window
Ubuntu package 3.7.3	`LC_CTYPE=zh_CN.UTF-8`	95–96%	Not shown
Ubuntu package 3.7.3	`LC_CTYPE=C.UTF-8`	14–15%	Shown
Ubuntu package 3.7.3	Chinese `LANGUAGE`, `LC_CTYPE=C.UTF-8`	15%	Shown
Ubuntu package 3.7.3	English `LANGUAGE`, `LC_CTYPE=zh_CN.UTF-8`	96%	Not shown
Official AppImage 3.7.8	Chinese locale	93%	Not shown
Official AppImage 3.7.8	`LC_CTYPE=C.UTF-8` only	93%	Not shown
Official AppImage 3.7.8	`LC_ALL=C.UTF-8`	12%	Shown

Repeated debugger samples of the Ubuntu package placed the main thread in:

NumericTextCtrl::ComputeSizing()
  → wxGCDCImpl::DoGetTextExtent()
  → wxCairoContext::GetTextExtent()
  → pango_layout_get_pixel_size()
  → Pango / Fontconfig / HarfBuzz

NumericTextCtrl::ComputeSizing() attempts to fit the literal "0" into an
11x19 digit box. After subtracting the top and bottom borders, the effective
height is 17 pixels:

while (strW > boxW || strH > boxH) {
    dc.SetFont(wxFont(--fontSize, wxFONTFAMILY_DEFAULT,
        wxFONTSTYLE_NORMAL, wxFONTWEIGHT_NORMAL));
    dc.GetTextExtent(wxT("0"), &strW, &strH);
}

With LC_CTYPE=zh_CN.UTF-8, "0" remains 8x22 while the requested point
size decreases. The loop has no minimum font size, iteration limit, or
no-progress check. Instrumentation observed 531,891 calls to
pango_layout_get_pixel_size() in 8 seconds, repeatedly returning 8x22.

Clean-environment isolation

The official 3.7.8 AppImage was tested in a rootless, clean Ubuntu Noble
rootfs under Xvfb. Crashpad was disabled only because it cannot initialize in
the rootless PID namespace; the same shim and environment were used for every
condition.

Clean-rootfs condition	CPU after 8 seconds	Main window
`zh_CN.UTF-8`, normal Ubuntu Fontconfig	9.3%	Shown
`zh_CN.UTF-8`, Kubuntu `56-kubuntu-noto.conf` injected	95.1%	Not shown
`C.UTF-8`, the same Kubuntu rule injected	9.2%	Shown

The injected file is supplied by kubuntu-settings-desktop 1:24.04.13. Its
Chinese-font rule changes any requested pixelsize <= 14 to 14 pixels. This
one rule is sufficient to reproduce the AppImage startup hang in the clean
rootfs. It also explains why a Lubuntu VM without the Kubuntu rule does not
reproduce.

A minimal wxGTK program using the same pixel-font constructor provides a fast
reproduction without Audacity. With the rule and zh_CN.UTF-8,
Noto Sans CJK SC measures 8x22 for every requested size from 10 pt through
1 pt. wxWidgets' pixel-size search finds no fitting size and leaves a font
that is valid but reports point size 0. Without the rule, the same rootfs
selects 8 pt and measures 6x17, which fits.

Forcing DejaVu Sans through a temporary Fontconfig rule also makes both the
minimal harness and the official AppImage start normally on the affected host.

Responsibility

This is a layered failure:

The Kubuntu Fontconfig rule intentionally imposes a 14-pixel minimum for
Chinese fonts. That is the environment-specific trigger, not an Audacity
packaging error.
wxWidgets converts the unsatisfied pixel-size request into a valid 0-point
font instead of exposing a usable failure to the caller.
Audacity turns that condition into an infinite startup loop because
NumericTextCtrl::ComputeSizing() has no minimum size, iteration limit, or
no-progress check.

Audacity should bound this loop and stop when the measured extent no longer
decreases. The official AppImage is affected because its text rendering still
observes the host Fontconfig/font policy.

Workaround

For the Ubuntu noble-backports package, both of these started the application
in the tested matrix:

LC_ALL=C.UTF-8 audacity
LC_CTYPE=C.UTF-8 audacity

For the official 3.7.8 AppImage, LC_CTYPE=C.UTF-8 alone still hung. The
working locale workaround was:

LC_ALL=C.UTF-8 ./audacity-linux-3.7.8-x64-22.04.AppImage

Using a Fontconfig policy without the 14-pixel Chinese minimum also avoids
the trigger.

Environment

OS: Ubuntu 24.04.4 with kubuntu-desktop / Kubuntu settings
Desktop: KDE Plasma on X11
kubuntu-settings-desktop: 1:24.04.13
Ubuntu package: 3.7.3+dfsg-1~bpo24.04.1 from noble-backports
wxWidgets: 3.2.4+dfsg-4build1
Pango: 1.52.1+ds-1build1
HarfBuzz: 8.3.0-2build2
Fontconfig: 2.15.0-1.1ubuntu2
fonts-noto-cjk: 1:20230817+repack1-3
Official AppImage: audacity-linux-3.7.8-x64-22.04.AppImage
AppImage SHA-256: 7ffe002a759ae9c99da1ee443364ae1fef3e179db69c4a0e47b13a0827a9168b

Current master uses the Qt/AU4 application path by default, while the
wxWidgets implementation described above is under the legacy AU3 source tree.
The current Qt-based development build has not been runtime-tested for this
issue.

Is this problem on the latest .AppImage version?

I have not tested the latest AppImage yet. This report currently applies to
the Ubuntu noble-backports package 3.7.3+dfsg-1~bpo24.04.1.

I have now reproduced the issue on the same machine and traced the hot loop.
The hang is not in wxLocale initialization as I originally suspected. It is
in NumericTextCtrl::ComputeSizing(), which repeatedly measures the literal
"0" while decreasing the font size without a lower bound or progress guard.

With LC_CTYPE=zh_CN.UTF-8, the Pango measurement remains 8x22, and the
loop made 531,891 calls to pango_layout_get_pixel_size() in 8 seconds.
Using LC_CTYPE=C.UTF-8 allows the same binary to start normally.

I have updated the issue body with the runtime findings. Since the AppImage
may bundle a different wxWidgets/Pango/font stack, its behavior still needs
to be tested separately.

As Audacity maintains only AppImage versions, then maybe better place to report this would be https://bugs.launchpad.net/ubuntu/+source/audacity/

Thanks. I have now tested the latest official Linux AppImage, and the issue
reproduces there as well, so it is not limited to the Ubuntu package.

Tested asset:

audacity-linux-3.7.8-x64-22.04.AppImage
SHA-256: 7ffe002a759ae9c99da1ee443364ae1fef3e179db69c4a0e47b13a0827a9168b
Kubuntu 24.04 / KDE Plasma / X11
Clean XDG_CONFIG_HOME and TMPDIR

Results after 8 seconds:

Locale condition	CPU	Main window
Chinese locale	93%	Not shown
`LC_CTYPE=C.UTF-8` only	93%	Not shown
`LC_ALL=C.UTF-8`	12%	Shown

The AppImage showed the same startup symptom: high CPU, only hidden
placeholder windows, and no main window. I have updated the issue body with
these results.

One correction to my previous findings: LC_CTYPE=C.UTF-8 alone is a working
workaround for the Ubuntu 3.7.3 package, but not for the 3.7.8 AppImage. The
AppImage required LC_ALL=C.UTF-8 in this test.

Tested on Lubuntu VM and AppImage, did not manage to reproduce.

Thanks — the Lubuntu VM result is consistent with the trigger I have now isolated.

I reproduced the official 3.7.8 AppImage in a clean Ubuntu Noble rootfs under Xvfb and changed one variable at a time:

Clean-rootfs condition	CPU after 8 s	Main window
`zh_CN.UTF-8`, normal Ubuntu Fontconfig	9.3%	Shown
`zh_CN.UTF-8`, with Kubuntu `56-kubuntu-noto.conf` injected	95.1%	Not shown
`C.UTF-8`, with the same Kubuntu rule injected	9.2%	Shown

The rule is supplied by kubuntu-settings-desktop 1:24.04.13. For fonts whose language contains zh, it clamps every requested pixelsize <= 14 to 14 pixels. A minimal wxGTK harness confirms that with this rule active, Noto Sans CJK SC measures 8x22 from 10 pt all the way down to 1 pt. wxWidgets pixel-size fitting therefore returns a valid font with point size 0, and Audacity then decrements below zero forever in NumericTextCtrl::ComputeSizing() because the loop has no lower bound or no-progress guard.

Without that Kubuntu Fontconfig rule, the same clean rootfs and AppImage start normally in the Chinese locale. So a Lubuntu installation is not expected to reproduce unless this rule (or an equivalent minimum-CJK-pixel-size rule) is present. This also explains why the official AppImage is affected: it still uses the host Fontconfig/font behavior.

There are layered robustness issues, but Audacity can prevent the startup hang by bounding the font-fitting loop and stopping when the measured extent no longer decreases.

This is 100% AI (checked by different AI detectors). If no real human is verifying the bug, then this issue might as well be closed.

@JIAFALSEDREAM

@JIAFALSEDREAM It is better not to use an LLM for generating reports. You may think giving the fullest, most detailed context possible is best, but for many, distinct LLM style and verbosity urge them to skip the issue.

Anyway, please try this build: #11848

@JIAFALSEDREAM It is better not to use an LLM for generating reports. You may think giving the fullest, most detailed context possible is best, but for many, distinct LLM style and verbosity urge them to skip the issue.

Anyway, please try this build: #11848

Sorry for dumping agent-generated reports into the issue. I’ll more careful next time.

I tested the build from #11848 three times. It works for me. Thanks!

Sorry, I closed this before noticing that the fix hadn’t been merged yet.

@JIAFALSEDREAM

@JIAFALSEDREAM no problem, we'll close the issue when merged

@dozzzzer

@dozzzzer @chinakov The freeze fix is confirmed, I don't think that you need to test it yourself. If anything, you can double check that the font size is the same in time code controls:

Fixes freeze on certain systems with incorrect font configuration (au…

Fixes freeze on certain systems with incorrect font configuration (#1… (

Navigation Menu

Repository navigation

[Linux] Audacity hangs at startup under zh_CN.UTF-8 locale #11623

Description

Steps to reproduce

Expected behavior

Actual behavior

Runtime investigation

Clean-environment isolation

Responsibility

Workaround

Environment

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

[Linux] Audacity hangs at startup under zh_CN.UTF-8 locale #11623

Description

Description

Steps to reproduce

Expected behavior

Actual behavior

Runtime investigation

Clean-environment isolation

Responsibility

Workaround

Environment

Activity

mrFlamel commented on Aug 28, 2026

JIAFALSEDREAM commented on Aug 28, 2026

mrFlamel commented on Aug 28, 2026

JIAFALSEDREAM commented on Aug 29, 2026

mrFlamel commented on Aug 30, 2026

JIAFALSEDREAM commented on Aug 31, 2026

mrFlamel commented on Aug 31, 2026

kryksyh commented on Aug 31, 2026

JIAFALSEDREAM commented on Aug 31, 2026

JIAFALSEDREAM commented on Aug 31, 2026

kryksyh commented on Aug 31, 2026

kryksyh commented on Aug 31, 2026

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions