Closed AtmosphericIgnition closed 11 hours ago
Was unable to reproduce on Ubuntu Linux (x64). Probably specific to Asahi or ARM
Also unable to reproduce on Fedora Linux (x64)
I get that ARM Linux is not officially supported, so if there is no easy fix to this issue, feel free to close this ticket, and I guess I'll stick to 7.41 for the foreseeable future.
It appears emulating asahi linux isn't something that is going to be easy; the only apple silicon emulator I can find seems to be focused on the iphone 11, rather than an apple mac. The device tree is going to be wildly different, so it's not going to just work out of the box.
It looks like the crash may be networking related:
INFO 2025-02-13T20:09:15.896Z background: navigator offline
INFO 2025-02-13T20:09:15.896Z SocketManager.onNavigatorOffline
INFO 2025-02-13T20:09:15.896Z SocketManager.check
INFO 2025-02-13T20:09:15.896Z WebSocketResources.KeepAlive(authenticated).send: Sending a keepalive message
INFO 2025-02-13T20:09:16.032Z background: navigator online
INFO 2025-02-13T20:09:16.032Z SocketManager.onNavigatorOnline
INFO 2025-02-13T20:09:16.032Z @signalapp/libsignal-client ConnectionManager: on_network_change libsignal_bridge_types::net rust/bridge/shared/types/src/net.rs:231
ERROR 2025-02-13T20:09:18.855Z Render process is gone: Error: Reason: crashed, Exit Code: 133
at App.<anonymous> ([REDACTED]/app/global_errors.js:94:7)
at App.emit (node:events:518:28)
at WebContents.<anonymous> (node:electron/js2c/browser_init:2:87957)
at WebContents.emit (node:events:518:28)
Is is completely possible that this is about something that's wrong with my system, I don't know if anything changed between 7.41 and 7.42+ that could surface a problem like this. I've tried to build Signal as a native ARM Flatpak so I could figure out if the issue is on my system, but I haven't been able to get it to build correctly.
Feel free to close this if you don't think this is worth investigating.
@AtmosphericIgnition Sorry, I didn't mean to imply that it was your fault or that we wouldn't investigate. Just sharing my initial findings, I don't have a workaround for you, but if you want to play around with it further, network related settings/etc may be a good starting place.
Oh yeah, no problem, I just meant to say that I understand that I'm trying to run Signal on a platform that isn't officially supported, so I understand if you don't have the resources to investigate this.
One more thing that might be the source of issues is that Asahi uses 16KB memory pages, while x86 uses 4KB pages, and have been issues with Chromium in the past where Google accidentally broke some functionality on systems using 16KB pages.
I'll go look into networking related changes, as well as check commits between 7.41 and 7.42 for anything that could be related.
signal build from official archive for manjaro aarch64. Bug appears from 7.42 Same crash when going to about signal desktop or open parameters, just wait a few second.
{"level":30,"time":"2025-02-17T22:57:42.682Z","msg":"config/set: Saved ephemeral config to disk"}
Render process is gone: Error: Reason: crashed, Exit Code: 133
at App.
[46444:0217/235802.658589:ERROR:wayland_event_watcher.cc(47)] libwayland: wl_buffer#39 still attached
[46444:0217/235802.658678:ERROR:wayland_event_watcher.cc(47)] libwayland: wl_buffer#49 still attached
[46444:0217/235802.658747:ERROR:wayland_event_watcher.cc(47)] libwayland: wl_buffer#45 still attached
[46444:0217/235802.658818:ERROR:wayland_event_watcher.cc(47)] libwayland: wl_buffer#46 still attached
[46444:0217/235802.658897:ERROR:wayland_event_watcher.cc(47)] libwayland: wl_shm_pool#47 still attached
I can boot under a 4k and a 16k kernel. Only 16k kernel had the crash.
@tartanpion are you using Asahi for the 16k page size kernel, or are you using a 16k kernel on a normally 4k system (or vice-versa)?
RPI5 can boot on a 4k or a 16k
I guess that we'll have to wait until Electron gets updated past the Chromium versions which caused the breakage. I don't have the exact range of Chromium versions which were affected by this, but I know that distros like Fedora had to carry a patch that removed the problematic commit for quite some time.
I believe this is the relevant issue on Chromium's issue bug tracker.
I guess that for now, ARM64 16k users have to either stick to 7.41, or use some custom version of Electron.
can you try --js-flags="--no-decommit-pooled-pages" .
Signal download their version of electron, not local. signal-desktop@7.42.0 electron:install-app-deps
electron-builder install-app-deps
• electron-builder version=26.0.0-alpha.8 • loaded configuration file=package.json ("build" field) • executing @electron/rebuild electronVersion=34.0.1 arch=arm64 buildFromSource=false appDir=./
electron is patched. Depends of signal team to pick up. https://github.com/electron/electron/pull/45571
I can confirm that using the --js-flags="--no-decommit-pooled-pages"
flag stops the issue from appearing.
I'm also experiencing this issue:
╭──────────────────┬───────────────────────────────────────────────────────────╮
│ kernel-name │ Linux │
│ nodename │ callisto │
│ kernel-release │ 6.12.12-asahi │
│ kernel-version │ #1-NixOS SMP PREEMPT_DYNAMIC Tue Jan 1 00:00:00 UTC 1980 │
│ machine │ aarch64 │
│ operating-system │ GNU/Linux │
╰──────────────────┴───────────────────────────────────────────────────────────╯
I'm running a patched version of the Fedora COPR on NixOS on an M1 Macbook Pro with the Asahi Linux kernel / mesa drivers. Will try the flag and see if it solves the problem.
Edit: flag seems to have fixed the issue.
same issue also happens on the arm64 signal flatpak, and solved by the same flag.
@nehemiagurl This is expected, as the bug originates in Chromium hardcoding the expected memory page size. Full system virtualization would be the only way to get around this.
This issue is exist with me on Raspberry Pi5, I am using a unofficial Debian package [https://gitlab.com/undef1/signal-desktop-builder/-/packages/](from this link) , the issue is solved by adding the flat --js-flags="--no-decommit-pooled-pages"
signal 7.45.1 use electronVersion=34.2.0. Will be fixed with https://github.com/electron/electron/releases/tag/v34.3.0
signal 7.45.1 use electronVersion=34.2.0. Will be fixed with https://github.com/electron/electron/releases/tag/v34.3.0
Yes, bumping electron to 34.3.x will fix the problem, see https://releases.electronjs.org/release/compare/v34.2.0/v34.3.2
Fixed an issue where Electron may experience crashes on Linux with 16KiB pages. #45571 (Also in 33)
@yash-signal Would it be possible to bump electron to the latest of the v34.x line, which currently is v34.3.3 - that would fix this problem here and is a very low hanging fruit.
Apologies for the extended trouble. I'll look into the Electron upgrade and update this issue when we have a beta to test.
@yash-signal Thanks! I am using betas anyway, so just let me know when you bumped to 34.3.3 so I can give feedback, thanks!
@yash-signal Actually, if possible, the best thing to do would be to upgrade electron straight to 35.0.1, because it is based on chromium 134 which actually fixes the underlying problem. Electron 34.3.3 only implements a workaround itself to work around the chromium bug (but should be good enough for the short term).
@yash-signal Actually, the workaround Electron shipped with version 34.3.0 is actually not working. So you need to bump electron to v35 to really fix this. Visual studio code just found out that the fix in v34.3.x in not effective: https://github.com/microsoft/vscode/issues/242742#issuecomment-2722580993
Electron has been bumped to 35.0.2, and it seems the crash no longer happens (at least on the Flatpak based on the stable build) even without the flags. I think this issue can be closed.
I can confirm also the problem is now fixed with the latest version. Thanks!
@nehemiagurl The issue is on ARM systems, the Flapak is x86-only.
@AtmosphericIgnition read my comment up the chain, i'm using a specific flatpak built for aarch64.
I am on aarch64 with 16k page size and can confirm the issue is fixed now with the latest Signal release
$ uname -m
aarch64
$ getconf PAGESIZE
16384
Using a supported version?
Overall summary
I initially encountered this issue issue while using a third-party package, but I've been able to reproduce this by following the instructions for building from source. GitHub won't allow me to submit this without checking the "I am running the official version of Signal" box.
I can reproduce this issue on: v7.42 of the unofficial package own build of 7.42 own build of main (eba4b8c00a4bffc6f1753bb0ed0a521f7fae383a)
I can't reproduce this on: My own build of 7.41 v7.41 of the unofficial package
Furthermore, my builds of 7.42+ cannot pass
npm test
. They throw the same error dialog box, which makes the tests stop.Steps to reproduce
I tried running Signal without the
--ozone-platform=wayland --use-tray-icon
flags, but nothing changed.Expected result
The application shouldn't crash.
Actual result
The application crashes with the following error:
Terminal output:
npm test of main (shortened):
I have no idea if this is a bug with Electron, or something about my system specifically, given that I can reproduce this on specific versions by building from source, I still thought this was worth reporting. No idea whether the issue also happens in the unofficial Flatpak, since there is no official build for ARM64 Linux (unlike for Windows and macOS), and Flathub only repackages the official Debian package.
Please let me know if you need any more info from me.
Screenshots
Unofficial package:
npm test
of main:Signal version
7.42 - v7.45.0-alpha.1
Operating system
Linux (Fedora Asahi Remix)
Version of Signal on your phone
7.33.2 (Android)
Link to debug log
(this log is from the unofficial package) https://debuglogs.org/desktop/7.42.0/bf5273461e3eb5fe5a85cfcb3ea7df1530bb5db5f331809bc4df311b6b7b8a0d.gz