search

dennisameling / Signal-Desktop

Signal — Private Messenger for Windows, Mac, and Linux
https://signal.org/download
GNU Affero General Public License v3.0
131 stars 5 forks source link

Since 6.19.0 I am not able to handle images and attached files #17

Open doxioxi opened 1 year ago

doxioxi commented 1 year ago

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.

244656397-c3aa11b2-7f92-4cdd-8c2b-c8e1e24fe12c

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 ;-)

dennisameling commented 1 year ago

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?

image

doxioxi commented 1 year ago

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.

bikinibabetpass commented 1 year ago

I confirm this bug. Debian 12 ARM. @dennisameling please try running on native ARM linux.

dennisameling commented 1 year ago

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 🙏🏼

doxioxi commented 1 year ago

the last working version 6.18.1 for me reached end of life and I am forced to update. Is there any solution?

dennisameling commented 1 year ago

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:

doxioxi commented 1 year ago

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.... ;-)

rovitotv commented 12 months ago

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

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

doxioxi commented 11 months ago

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

yizeky commented 11 months ago

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:

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

zylzyz commented 10 months ago

here is related conversation using arm64 architecture. scroll up and down. https://forum.pine64.org/showthread.php?tid=18367&pid=120473#pid120473

yizeky commented 10 months ago

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:

My workaround:

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.

zylzyz commented 8 months ago

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.

Peter-lalala commented 6 months ago

Some observations here:

  1. On Raspberry Pi4, NO issue with the Ubuntu 22.04.4 + Snap version (latest as of 2024.3.7)

  2. On Raspberry Pi4, same issue with PiOS/x11 (aarch64 bookworm) + Snap version (latest as of 2024.3.9)

  3. On Raspberry Pi4, same issue with PiOS/x11 (aarch64 bookworm) + Pi-Apps version 7.1.1

I guess #1 may provide some clues?

CarstenKochElsdorf commented 6 months ago

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.

doxioxi commented 4 months ago

On Raspberry Pi5, NO issue with 2024-03-15-raspios-bookworm-arm64 + deb version 7.11.0

dennisameling commented 3 weeks ago

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.

doxioxi commented 3 weeks ago

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

Peter-lalala commented 3 weeks ago

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.

dennisameling commented 2 weeks ago

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.

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

CarstenKochElsdorf commented 1 week ago

I just tested your 7.25.0 on my Orange Pi 5 and I can confirm that it is working now. :-)

yizeky commented 1 week ago

@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!

yizeky commented 1 week ago

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.