Attaching a specific PDF file results in an error and crash. The file draft then cannot be dismissed.

[nehemiagurl]

Attaching a specific PDF file results in the following error, then a crash:

Render process is gone

Error: Reason: killed, Exit Code: 3 at App. ([REDACTED]/app/global_errors.js:94:7) at App.emit (node:events:519:28) at WebContents. (node:electron/js2c/browser_init:2:87106) at WebContents.emit (node:events:519:28)

App Version: 7.28.0 OS: linux

The file isn't corrupted and can be opened normally in Okular. No other PDF file seems to cause this error. Once attaching this file to a chat, a draft with the broken attachment be created. The file can't be removed from the message, nor can the message be sent empty like with usual attachments. Screencast_20241014_180151.webm However, when typing text into the message box and sending, a regular, attachment-less message is sent.

Is this something to send to upstream? Is this an issue with this specific version?

[adamthiede]

Thanks for the report. A few questions:

• which architecture and package format? This repo provides flatpaks and .debs for arm64 and amd64.
• Would you be comfortable sharing the pdf?
• Does this happen also with the flathub flatpak or signal's official .deb?

[nehemiagurl]

I am using the arm64 flatpak. As the PDF contains far too much personal information I will not be sharing it. Sorry. I understand this may prove challenging to debug for that reason. Just had someone test the same file on the Flathub Flatpak on x86_64 and the issue is not reproducible on their end. I'll try and see if I can also get an ubuntu machine and test with the official .deb.

[adamthiede]

Thanks - and no worries on not sharing the PDF. It's just that attachment though, and other things work fine? Is it really big?

Currently the portal stuff is broken on this flatpak due to upstream electron issues, and we've not changed the flatpak to request full disk access, since that's not a great idea I think. Have you used flatseal or something else to give the flatpak permissions to attach files, or did you move the pdf to the .var/app/org.signal.Signal directory?

See here for info on the portals issue.

[nehemiagurl]

it's just this attachment. nothing else seems to trigger it. the file is simply in the Downloads folder - all other downloads folder files work just fine. the file isn't particularly big, it's actually quite small - only 73KB. I didn't use flatseal, at least not directly - I've used KDE's built in "Flatpak permission" to grand access to grant filesystem access to specific paths (Downloads among them) so I can select files from there. Nothing beyond that.

[adamthiede]

If you run signal from the command line (flatpak run org.signal.Signal) what is the output it gives when adding the attachment? If you have a way to modify the pdf (maybe add a comment or annotate it somehow?) does the modified version trigger it?

[nehemiagurl]

I figured out what differentiates this file from other files! It contains Hebrew characters in the file name. I tried changing other files to have even a single Hebrew character in their name, and they also resulted in a crash. using a random pic from Wikimedia to test, this file titled test file 1.jpg loads normally: but take the same file, don't even duplicate it just rename it to test file 1א.jpg, and it crashes:

very weirdly though, when starting Signal from the command line, the file uploads normally. when starting from the GUI (be it KDE's Task Manager or Application Launcher or even from Discover) it still crashes. this is true for all files tested containing Hebrew characters. this doesn't resolved previously failed uploads though, the issue documented in this video I've uploaded earlier still holds and the way to dismiss is still the same (add text and send the message which will be sent without the attachment). only new uploads when starting from the command line aren't affected.

[adamthiede]

Well that's not ideal; I assume if you've got one file with Hebrew characters you've probably got more.

What OS are you using? I don't use KDE but I assume there's a way to tell it which locale(s) to use. Something tells me that it's probably a configuration issue given that it works correctly from the command line.

If you modify the .desktop file or create a custom one and use something like flatpak run org.signal.Signal for the Exec line, I wonder if that may help.

(On Alpine Linux + GNOME, I was able to send myself a few Hebrew bird pictures no problem, so maybe it's just either something with KDE or your setup?)

[nehemiagurl]

I'm running Fedora Asahi Remix on a Mac (hence ARM64 and using this instead of the flathub flatpak) with KDE Plasma 6.2.0. The application launcher .desktop file is as follows: Exec=/usr/bin/flatpak run --branch=master --arch=aarch64 --command=signal-desktop --file-forwarding org.signal.Signal @@u %U @@ so it doesn't look like this is the source of the problem? I mean running that exec line in the terminal results in a non-crashing version. I must admit I'm not that versed in flatpak .desktop files. there are ultimately two .desktop files nested somewhere within ~/.local/share/flatpak/app/org.signal.Signal, one has the same exec line as the application launcher's, the second has: Exec=signal-desktop %U edit: oh and editing the second exec line to be the same as the first (which as mentioned we know works when run from the command line) didn't solve the problem. I ended up reverting that change because as mentioned not that versed in flatpak .desktop files and I didn't want to break something :sweat_smile:

[adamthiede]

I just installed a Fedora 40 KDE spin VM and was not able to reproduce the issue. Granted the difference is x86 vs arm64, and I'm not sure how closely Asahi tracks "real" Fedora, but I'd expect they are similar. I've run dnf list --installed and put the list here: https://termbin.com/x8mq Maybe compare your installed packages to this one? See if this list has any you don't have.

[adamthiede]

Oh, and another question - is this using a "user" or "system" remote? If one, maybe try the other?