Cannot start on Asahi Linux

[uetcis]

Steps to reproduce

Try launching telegram-desktop.

Expected behaviour

TG should function on 16K page systems.

Actual behaviour

Crash immediately with the following error:

<jemalloc>: Unsupported system page size
GLib (gthread-posix.c): Unexpected error from C library during 'malloc': Cannot allocate memory.  Aborting.
[1]    150580 IOT instruction (core dumped)  ./telegram-desktop

Operating system

Asahi Linux (ARM), KDE Plasma 5.24.5, Qt 5.15.4

Version of Telegram Desktop

3.7.3

Installation source

Snap

Logs

No response

[ilya-fedin]

TG should function on 16K page systems.

It's unlikely to be fixed unless a patch by a user with such system would be contributed.

[uetcis]

@ilya-fedin Seems it can be fixed by rebuilding jemalloc so that it can support 16K pages as shown here.

[ilya-fedin]

Won't that break all other systems?

[uetcis]

Won't that break all other systems?

@ilya-fedin That's not supposed to break other systems. For the explanation you may take a look at the discussions in the PR link I posed above.

[ilya-fedin]

I'm afraid to change jemalloc defaults and I don't really think that TG should function on 16K page systems, IIRC from Phoronix article, 16K page size is a temporary solution, so I think it's better just to wait until Asahi Linux start to use the common page size.

[uetcis]

I'm afraid to change jemalloc defaults and I don't really think that TG should function on 16K page systems, IIRC from Phoronix article, 16K page size is a temporary solution, so I think it's better just to wait until Asahi Linux start to use the common page size.

@ilya-fedin The problem is that Asahi Linux will not use "common" page sizes. It would be great if you can take a look at the page here: https://github.com/AsahiLinux/docs/wiki/Broken-Software

[Aokromes]

i don't think preston will want to release a specific version for 0.01% or less userbase.

[xvitaly]

You can build tdesktop from sources against the packaged version of jemalloc. It should work fine.

[uetcis]

Actually no specific version is going to be required. Rebuilding jemalloc for 16K is not supposed to break it on 4K platforms, and such support could be required for "proper support of AArch64" as Asahi-Linux developers claim that not supporting 16K page size is an "incomplete support for AArch64". In fact, projects like Chromium and Emacs have recently added support for 16K pages on Arm after realizing that.

But of course eventually it would be at your discretion whether or not to add official support for it. And in the case you decide not to do so, I would be grateful if someone can offer some help to me so that I can build Telegram on Arm and make a custom PKGBUILD for it. (I'm not sure if the documented building process using docker would work for Arm builds.)

[lillycat332]

I'm afraid to change jemalloc defaults and I don't really think that TG should function on 16K page systems, IIRC from Phoronix article, 16K page size is a temporary solution, so I think it's better just to wait until Asahi Linux start to use the common page size.

This just isn't true - The M1 natively uses 16K page sizes, and to use other page sizes isn't great for performance in Linux. macOS gets away with it because it supports multiple page sizes in userspace, to my knowledge Linux doesn't have this.

[ilya-fedin]

Asahi-Linux developers claim that not supporting 16K page size is an "incomplete support for AArch64"

What should be stated first apparently is there's no official support for anything other than x86_64 on Linux. That is, launchpad builds variants for other architectures on its own as well as flathub, but the only build that is fully official and is tested is the static binary from official website.

Next, for static binary/flatpak/snap jemalloc is built as an external cmake project. Thus, we apparently need a way to detect aarch64 via cmake. That's not something I'd really like to do as that would look hacky most likely. At the same time, even though enlarging the page size wouldn't break the binary, it's not clear which side effects it can produce. I.e. influence on memory footprint, etc. I'm afraid to do such a change for all architectures until it's all would be clear.

Of course, you will have way more chances to propose this change if jemalloc change the default (only for aarch64?), so it will be clear it's the recommended value and there's no worries. It's also better to fix once and for all in jemalloc than in every consumer.