Since 6.19.0 I am not able to handle images and attached files
doxioxi opened this issue · 37 comments
Since 6.19.0 it is impossible for me to paste images or to see attached files on Signal Desktop under Debian 11 (bullseye).
When pasting a screenshot from the clipboard, the application rests in the loading-state. Clicking on the symbol for attaching files opens the file-browser and I am able to choose a file, but it never appears and the application is also resting in the loading-state to infinity (any file-type, it is not an issue with the preview of pictures). When receiving any attachment (any file-type) or a foto, I am not able to open it or to download it to the disk and pictures are not getting a preview.
For the moment I hold the working version 6.18.1
debug log is here
I have already asked in the report box of the official build and I was told that something is going wrong at a very low level:
ERROR 2023-06-12T19:03:27.805Z Top-level unhandled promise rejection: Error: EFAULT: bad address in system call argument, write
ERROR 2023-06-12T19:05:04.482Z Top-level unhandled promise rejection: Error: EFAULT: bad address in system call argument, write
ERROR 2023-06-12T19:07:53.765Z Top-level unhandled promise rejection: Error: EFAULT: bad address in system call argument, write
The other inofficial arm64 build provided as a flatpak app shows exactly the same behaviour.
Any ideas?
Thanks in advance ;-)
I just tried this with the latest release on Debian 11 arm64 through WSL (Windows Subsystem for Linux) and am not running into the issue you described. Could you please ensure that your OS is fully up to date, ensure that Signal has the correct read/write permissions and try again?
I can not confirm this. I tried the following: I took a fully fresh debian 12 image for my Raspberry Pi and only put the latest release and it shows exactly the same behaviour as under my everyday running fully updated debian 11 environment.
I confirm this bug. Debian 12 ARM. @dennisameling please try running on native ARM linux.
Hmm, interesting. I currently don't have the bandwidth to look further into this, sorry. Maybe if you post in this issue, someone in there might be able to help debug this issue a bit further 🙏🏼
the last working version 6.18.1 for me reached end of life and I am forced to update. Is there any solution?
I haven't seen anyone come up with a solution yet, but the following questions might help someone who has the bandwidth to dive further into this:
- Is this only happening on Debian 11 + 12 on arm64? Any other OSes that are facing the same issue?
- What hardware are you running it on? As mentioned above, I couldn't reproduce on Windows 11 on arm64 with Debian 11 on a Surface Pro X. I see Raspberry Pi mentioned above - which model exactly?
- I'm currently building Signal Desktop for Linux arm64 using CircleCI's
ubuntu-2004image (Ubuntu 20.04 LTS). Not sure if that could have any impact at all on this. - Have you looked at this issue already? It looks like some folks there were having similar issues.
The issue is solved for me. First I got it to work with ubuntu 22.04.3 LTS for Raspberry Pi, then also with the lastest image taken today from https://raspi.debian.net/daily-images/. So I think it's time to switch completely to debian 12 bookworm and there is no need to search why it did not work until now.
Thank you Dennis for insisting in trying to reproduce it on different OS images and moreover for providing here the arm64-version for the signal-desktop.... ;-)
I have the same problem with a Raspberry Pi 4 on the lastest Raspberry Pi OS (Debian Bullseye version 11) with Signal Desktop Unofficial 6.33.0. The images don't resolve. I installed the Signal Desktop Unofficial deb package with the following command:
sudo apt install -f ./signal-desktop-unofficial_6.33.0_arm64.debhere is output from neofetch:
_,met$$$$$gg. rovitotv@raspad
,g$$$$$$$$$$$$$$$P. ---------------
,g$$P" """Y$$.". OS: Debian GNU/Linux 11 (bullseye) aarch64
,$$P' `$$$. Host: Raspberry Pi 4 Model B Rev 1.5
',$$P ,ggs. `$$b: Kernel: 6.1.21-v8+
`d$$' ,$P"' . $$$ Uptime: 7 hours, 25 mins
$$P d$' , $$P Packages: 1724 (dpkg)
$$: $$. - ,d$$' Shell: bash 5.1.4
$$; Y$b._ _,d$P' Resolution: 1280x800, 1920x1080
Y$$. `.`"Y$$$$P"' DE: LXDE
`$$b "-.__ WM: Mutter
`Y$$ WM Theme: Adwaita
`Y$$. Theme: PiXflat [GTK3]
`$$b. Icons: PiXflat [GTK3]
`Y$$b. CPU: BCM2835 (4) @ 1.800GHz
`"Y$b._ Memory: 1999MiB / 7812MiB
Despite this bug it is still a miracle this is working! Thank you so much.
With Debian Bullseye version 11 it was expectable but it's even worse: Same issue again with brand new Raspi OS released in Oct 2023 (based on Debian version 12 bookworm) together with signal-desktop-unofficial_6.34.0
OS: Debian GNU/Linux 12 (bookworm) aarch64
Host: Raspberry Pi 400 Rev 1.0
Kernel: 6.1.0-rpi4-rpi-v8
I am facing the same issue in the linux container of the arm based Chromebook. I am also seeing 'EFAULT: bad address in system call argument, write' in the log.
Originally I was using the unofficial build for the arm. The issue still occurred even though it is built from source code (v6.36.0) on my linux container of the arm Chromebook.
When I run yarn test, test-electron was failing by the same EFAULT:
-
Attachments createReader should read file from disk
Error: EFAULT: bad address in system call argument, write -
Attachments copyIntoAttachmentsDirectory returns a function that copies the source path into the attachments directory and returns its path and size
Error: EFAULT: bad address in system call argument, write -
Attachments createWriterForExisting should write file to disk on given path and return path
Error: EFAULT: bad address in system call argument, write -
Attachments createWriterForNew should write file to disk and return path
Error: EFAULT: bad address in system call argument, write -
Attachments createDeleter should delete file from disk
Error: EFAULT: bad address in system call argument, write
Is this electron related issue on the arm?
Additionally I confirmed by strace command to check which write systemcall is failing:
(Error message is Japanese)
..(snip)..
[pid 3540] write(66</home/user01/.config/Signal/badges.noindex/84/84e143bc387a605eab327145ada974a653b0df718716dea44eb600dc8ad7becf.svg>, "", 0 <unfinished ...>
[pid 3540] <... write resumed>) = -1 EFAULT (不正なアドレスです)
[pid 3537] write(67</home/user01/.config/Signal/badges.noindex/14/14e331ce7fc432a748edfb9eb8d4beb3b538bcab6ee78c7b3c1be11a0f79813e.svg>, "", 0 <unfinished ...>
[pid 3537] <... write resumed>) = -1 EFAULT (不正なアドレスです)
[pid 3538] write(66</home/user01/.config/Signal/badges.noindex/c5/c5e4a954260d0a0f87af8183a2eb1f7d4c55f3c7edfe12621db82628a16cd8bf.svg>, "", 0 <unfinished ...>
[pid 3538] <... write resumed>) = -1 EFAULT (不正なアドレスです)
[pid 3539] write(69</home/user01/.config/Signal/attachments.noindex/83/831057c29adaee8a3adf6fecbde0f7dfcc9ded303bbacd467226384dd6066cf0>, "", 0 <unfinished ...>
[pid 3539] <... write resumed>) = -1 EFAULT (不正なアドレスです)
[pid 3540] write(69</home/user01/.config/Signal/attachments.noindex/4f/4f0f6180ebf8432bbf37faed141e449fb1a96b093d7e1605a3eca0c7a156a79a>, "", 0 <unfinished ...>
[pid 3540] <... write resumed>) = -1 EFAULT (不正なアドレスです)
write systemcall for the files under .config/Signal/attachments.noindex and badges.noindex are failing by empty 2nd parameter with 0 byte count write e.g. write("xxx", "", 0); causes EFAULT.
========= System info =========
App version: 6.36.0
Environment: production
Linux version: "Debian GNU/Linux 11 (bullseye)"
Node version: 18.15.0
OS version: #1 SMP PREEMPT Fri Oct 13 18:24:10 PDT 2023
Time: 1698566202267
User agent: Mozilla/5.0 (X11; Linux aarch64) AppleWebKit/537.36 (KHTML, like Gecko) Signal/6.36.0 Chrome/114.0.5735.289 Electron/25.8.4 Safari/537.36
here is related conversation using arm64 architecture. scroll up and down.
https://forum.pine64.org/showthread.php?tid=18367&pid=120473#pid120473
fse.ensureFile() call seems to be causing EFAULT of the write systemcall in arm64 environment.
I am not expert of node.js but I think:
- ensureFile is implemented by fs-extra/lib/ensure/file.js as function createFile (file, callback)
- createFile() is calling fs.write(file, '') in order to create empty file to target path.
- fs.write() is dispatched to write() systemcall, but when 2nd parameter of fs.write() is empty (''), 2nd parameter of write systemcall is pointing invalid address.
My workaround:
- Change fs.write(file, '') => fs.write(file, ' ') on node_modules/fs-extra/lib/ensure/file.js
Then now, I can send/receive attachments without EFAULT in my aarch64 chromebook linux.
I think root cause could be node.js or libuv? (somewhere dispatching to the write systemcall).
When empty buffer parameter passed to fs.WriteFile(), invalid const void *buf address is generated as the write() syscall parameter.
this bug still occurs in 6.45.
filename:
signal-desktop-unofficial_6.45.0_arm64.deb
os:
mobian trixie, kernel, Linux mobian 6.6-sunxi64.
device:
pinephone regular.
Some observations here:
-
On Raspberry Pi4, NO issue with the Ubuntu 22.04.4 + Snap version (latest as of 2024.3.7)
-
On Raspberry Pi4, same issue with PiOS/x11 (aarch64 bookworm) + Snap version (latest as of 2024.3.9)
-
On Raspberry Pi4, same issue with PiOS/x11 (aarch64 bookworm) + Pi-Apps version 7.1.1
I guess #1 may provide some clues?
I am seeing the same bug on
Hardware: Orange Pi 5
Software: Ubuntu 22.04.3 LTS Jammy Jellyfish
Linux opim 5.10.110-rockchip-rk3588 #1.1.6 SMP Thu Jun 1 21:23:54 CST 2023 aarch64 aarch64 aarch64 GNU/Linux
Until yesterday I built signal-desktop myself (and was seeing the same bug), so I was looking forward to a better version when I downloaded https://github.com/dennisameling/Signal-Desktop
Quite disappointingly, the bug also exists here.
On Raspberry Pi5, NO issue with 2024-03-15-raspios-bookworm-arm64 + deb version 7.11.0
Hi all, I just published v7.24.0, which was built with Ubuntu 22.04 instead of 20.04 which I was using until today. Also, the Signal team has recently updated the NodeJS and Electron versions.
I'm curious if all these upgrades across the board make any difference for y'all.
If the issue still occurs, we might want to look into @yizeky's great investigative work. I noticed that Signal Desktop uses an almost 7 year old version of fs-extra, so if the bug is still present, I could try to upgrade it to the latest 11.2.0 in my fork (from 2023), or we might be able to come up with a small reproducer.
luckily continue with NO issue on my Raspberry Pi5 with updated 2024-03-15-raspios-bookworm-arm64 and the brand new deb version 7.24.0
Thanks for the new version. Still out of luck on my Raspberry Pi4 with latest Raspberry PiOS downloaded today (13 Sep 2024). Not tried on Pi4+Ubuntu this time though.
fse.ensureFile() call seems to be causing EFAULT of the write systemcall in arm64 environment. I am not expert of node.js but I think:
* ensureFile is implemented by fs-extra/lib/ensure/file.js as function createFile (file, callback) * createFile() is calling fs.write(file, '') in order to create empty file to target path. * fs.write() is dispatched to write() systemcall, but when 2nd parameter of fs.write() is empty (''), 2nd parameter of write systemcall is pointing invalid address.My workaround:
* Change fs.write(file, '') => fs.write(file, ' ') on node_modules/fs-extra/lib/ensure/file.jsThen now, I can send/receive attachments without EFAULT in my aarch64 chromebook linux.
I think root cause could be node.js or libuv? (somewhere dispatching to the write systemcall). When empty buffer parameter passed to fs.WriteFile(), invalid const void *buf address is generated as the write() syscall parameter.
@yizeky thanks so much for taking the time to dive in and share your findings here!
I was able to reproduce the issue on a Raspberry Pi 4 with the latest Pi OS (based on Debian 12, kernel 6.6.47+rpt-rpi-v8). However, when I applied your changes, I ran into other errors instead:
Failed to decrypt attachment Error: error:1e00007b:Cipher functions:OPENSSL_internal:WRONG_FINAL_BLOCK_LENGTH
I assume that's because the file that would normally be empty, now contains a space, causing the decryption/encryption process to fail.
Instead, I updated the patch to simply ignore these errors on Linux arm64. That's because, strangely enough, the empty files do get created just fine on the filesystem in my testing. With this fix applied, I was able to successfully work with attachments on the Raspberry Pi 4 with Pi OS (Debian 12).
Here's the updated .deb artifact for 7.25.0 that includes the fix: https://github.com/dennisameling/Signal-Desktop/releases/tag/v7.25.0
I'd love to report this upstream, but am struggling to create a reproducer. Within Signal itself, the issue seems to start at AttachmentCrypto.ts which calls ensureFile from fs-extra as you mentioned. That method writes files into /home/dennis/.config/Signal Unofficial/downloads.noindex/LONG_RANDOM_KEY_HERE. The weird thing is that, as mentioned above, the files do get created despite the error popping up!
This minimal sample works fine on Node itself:
import pkg from 'fs-extra'
const {ensureFile} = pkg
import {open} from 'fs/promises'
let writeFd;
const path = "/home/dennis/.config/Signal Unofficial/downloads.noindex/aafa9baa4153fd5d91b9e7a5bc4b22f10a73d97f9291ef60b1cad6b860352c8f"
try {
await ensureFile(path)
writeFd = await open(path, 'w')
} catch (cause) {
throw new Error('Failed to create write path', {cause})
}If someone could help me come up with a minimal reproducer, that'd be amazing, so I can report it upstream.
I just tested your 7.25.0 on my Orange Pi 5 and I can confirm that it is working now. :-)
@dennisameling -san, I confirmed the new v7.25.0, and it is working perfectly in my linux container (Deb 12) on the aarch64 chromebook, thank you very much for your update!
Regarding minimal reproducer, I feel it might be caused by the write() systemcall on the Electron + node.js/libuv combination. I saw many of the EFAULT errors of the write() systemcall when I run 'yarn test-electron' in the Signal-Desktop source tree. So if it is possible to create a similar style (electron base?) of unit-test case which contains just ensureFile() call could be a candidate.
This happened for the longest time for me, but it has been working reliably with the latest version for the past two weeks.